www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Specification driven development.

reply Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
Hi, All!

Is it possible to develop software on D in specification driven manner?

In specification driven development module specification is primary
and module implementation is derivative from module specification
(implementation skeleton cat be generated from specification) . So, at
first we write module specification. After that we wrote module
implementation. Compiler MUST check module implementation for
compliance with module specification.

In implementation MUST be implemented all public entity (function,
types and so on) from module specification. Also module implementation
can't implement another public entity.

It is useful for big projects.

------------------------

PS. It seems like we even can't use "headers" in D like in C++. For
example this code:
---
import std.stdio;

void foo() { writeln("A"); }
void foo() { writeln("B"); }
void main() {}
---
cause no errors in compilers frontend or backend. There is only linker error.
Oct 24 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Alexey Veselovsky:


 Is it possible to develop software on D in specification driven manner?


This is not how you normally write D code. Maybe there are ways to do this any
way, but they are not native.



 So, at
 first we write module specification. After that we wrote module
 implementation. Compiler MUST check module implementation for
 compliance with module specification.


D modules are a single file, normally they are not meant to be split in
specification and implementation parts.



 PS. It seems like we even can't use "headers" in D like in C++.


Right. This is by design. On the other hand there are "di" files, usually
self-generated.



 cause no errors in compilers frontend or backend. There is only linker error.


I'd like the compiler to find such mistakes before the linker, and give
appropriate error messages.
There are some bug reports on this.

Bye,
bearophile
Oct 24 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/24/2011 11:27 PM, bearophile wrote:

 Alexey Veselovsky:


 Is it possible to develop software on D in specification driven manner?


 This is not how you normally write D code. Maybe there are ways to do this any
way, but they are not native.


D has built-in unit test and DbC facilities.


 So, at
 first we write module specification. After that we wrote module
 implementation. Compiler MUST check module implementation for
 compliance with module specification.


 D modules are a single file, normally they are not meant to be split in
specification and implementation parts.



 PS. It seems like we even can't use "headers" in D like in C++.


 Right. This is by design. On the other hand there are "di" files, usually
self-generated.


Note that .di files are a lot like header files. They are just not 
usually required for development.
Oct 24 2011
prev sibling parent reply Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
 D modules are a single file, normally they are not meant to be split in
specification and implementation parts.


Hm... It is possible to split this single file to specification and
implementation part (in single file, not split to 2 different files)?
Like in Haskell for example or Object Pascal.
Oct 24 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/25/2011 12:07 AM, Alexey Veselovsky wrote:

 D modules are a single file, normally they are not meant to be split in
specification and implementation parts.


 Hm... It is possible to split this single file to specification and
 implementation part (in single file, not split to 2 different files)?
 Like in Haskell for example or Object Pascal.


You could maybe put contracts on interface methods and then implement 
those interfaces (even from different source files). But DbC has not 
gotten too much attention from the compiler developers lately, so I 
think there might be some unresolved bugs in DbC.
Oct 24 2011
parent reply Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
 Hm... It is possible to split this single file to specification and
 implementation part (in single file, not split to 2 different files)?
 Like in Haskell for example or Object Pascal.


 You could maybe put contracts on interface methods and then implement those
 interfaces (even from different source files). But DbC has not gotten too
 much attention from the compiler developers lately, so I think there might
 be some unresolved bugs in DbC.


Yep. Looks like in D only one way for real modularity: emulate it via
OOP (like in c++ or java, where all is object (yes, I know, in C++ not
all is object, but in C++ module is emulated via classes and
objects)).
Oct 24 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/25/2011 12:48 AM, Alexey Veselovsky wrote:

 Hm... It is possible to split this single file to specification and
 implementation part (in single file, not split to 2 different files)?
 Like in Haskell for example or Object Pascal.


 You could maybe put contracts on interface methods and then implement those
 interfaces (even from different source files). But DbC has not gotten too
 much attention from the compiler developers lately, so I think there might
 be some unresolved bugs in DbC.


 Yep. Looks like in D only one way for real modularity: emulate it via
 OOP (like in c++ or java, where all is object (yes, I know, in C++ not
 all is object, but in C++ module is emulated via classes and
 objects)).


Eventually it should be possible to put contracts on free function 
declarations (with the current language version, it only works for 
function definitions). But I am sure that OOP is not the only way to get 
real modularity in D. Given it's compile-time capabilities it is 
probably already possible to implement some ad-hoc system to allow for 
nice modular specification driven development. The language is pretty 
flexible. What would be the ideal set of features to support modularity 
in your opinion?
Oct 25 2011