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
next sibling 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 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 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
prev sibling next sibling parent 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
prev sibling parent 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