digitalmars.D - Specification driven development.
- Alexey Veselovsky <alexey.veselovsky gmail.com> Oct 24 2011
- bearophile <bearophileHUGS lycos.com> Oct 24 2011
- Timon Gehr <timon.gehr gmx.ch> Oct 24 2011
- Timon Gehr <timon.gehr gmx.ch> Oct 24 2011
- Timon Gehr <timon.gehr gmx.ch> Oct 25 2011
- Alexey Veselovsky <alexey.veselovsky gmail.com> Oct 24 2011
- Alexey Veselovsky <alexey.veselovsky gmail.com> Oct 24 2011
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
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
Timon Gehr <timon.gehr gmx.ch> 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
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
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
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
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