www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Assertions and modules

reply Sjoerd van Leent <Sjoerd_member pathlink.com> writes:
Currently I am using D pretty havily and I got across something to do with
assertions and modules.

I use assertions quite havily due to the design and because I like design by
contract. However I thing there could be one extension to it making assertions
even more powerful. When an assertion fails, normally an AssertionError is
thrown into the application, however, in for example a Date class, you might
want to throw a different exception when such behaviour occurs, for example an
ImpossibleDateException.

Syntatically it could very well look like

invariant throw ImpossibleDateException {
assert(day > 0 && day < 31);
..
}

The same goes for the in and out conditional checks with functions.

As for modules, which are a good thing, I have one struggle, it would be very
handy if it was possible to specify a module within different files (without
importing submodules or something in that manner). This makes it possible to
write out module implementations across different files, which for large code
segments, is very welcome. Another design might be to use path-extraction, what
Java does, for modules, but I don't know if this is feasible. Something like
partial modules may also be a solution to this, where a "boss" module dictates
which files may partially implement a module.
Sep 18 2004
parent Deja Augustine <deja scratch-ware.net> writes:
Sjoerd van Leent wrote:

 Currently I am using D pretty havily and I got across something to do with
 assertions and modules.
 
 I use assertions quite havily due to the design and because I like design by
 contract. However I thing there could be one extension to it making assertions
 even more powerful. When an assertion fails, normally an AssertionError is
 thrown into the application, however, in for example a Date class, you might
 want to throw a different exception when such behaviour occurs, for example an
 ImpossibleDateException.
 
 Syntatically it could very well look like
 
 invariant throw ImpossibleDateException {
 assert(day > 0 && day < 31);
 ..
 }
 
 The same goes for the in and out conditional checks with functions.
 
 As for modules, which are a good thing, I have one struggle, it would be very
 handy if it was possible to specify a module within different files (without
 importing submodules or something in that manner). This makes it possible to
 write out module implementations across different files, which for large code
 segments, is very welcome. Another design might be to use path-extraction, what
 Java does, for modules, but I don't know if this is feasible. Something like
 partial modules may also be a solution to this, where a "boss" module dictates
 which files may partially implement a module.
 
 
If you wanted to throw a different exception, you could just simply do: invariant { if(day < 0 || day > 31) throw new ImpossibleDateException(...); } If you wanted to do multiple assert statements, just combine them with logical operators. I see no reason to add a few hundred lines of code to the frond-end just to handle throwing an exception other than AssertException when an assert() statement is reached. -Deja
Sep 18 2004