Hi,
- PocketPC support would be very welcome...
- DbC (Design by Contract) idem ditto, see also viewtopic.php?t=14498&highlight=design+contract...
High on my wishlist: PocketPC support and DbC...
-
dell_jockey
- Enthusiast
- Posts: 767
- Joined: Sat Jan 24, 2004 6:56 pm
.-
dell_jockey
- Enthusiast
- Posts: 767
- Joined: Sat Jan 24, 2004 6:56 pm
-
DoubleDutch
- Addict
- Posts: 3220
- Joined: Thu Aug 07, 2003 7:01 pm
- Location: United Kingdom
- Contact:
But most of the os calls are the same (once the ARM cpu is supported). 
https://deluxepixel.com <- My Business website
https://reportcomplete.com <- School end of term reports system
https://reportcomplete.com <- School end of term reports system
dell_jockey,
Out of curiosity, what would you want to achieve with DbC?
Would you be satisfied with a good automated testing framework, like xUnit or Fit?
http://fit.c2.com/
http://www.junit.org/
I appreciate that DbC means much more than these, but that is within an Object Oriented context.
Out of curiosity, what would you want to achieve with DbC?
Would you be satisfied with a good automated testing framework, like xUnit or Fit?
http://fit.c2.com/
http://www.junit.org/
I appreciate that DbC means much more than these, but that is within an Object Oriented context.
-
dell_jockey
- Enthusiast
- Posts: 767
- Joined: Sat Jan 24, 2004 6:56 pm
Hi GedB,
unit- or blackbox-testing certainly has its merits. Thanks for those links! I'd like to have DbC to instrument my functions/procedures on a somewhat lower level, to ascertain that:
- the contracts guarantee that the function/procedure works as intended
- error reports are as meaningful as possible and are pointing to the real cause of the error
- to automatically generate documentation about contracts, function interfaces in general, etc.
Only after ascertaining that the lower level stuff works as advertised, unit- or blackbox-testing becomes very meaningful, because errors found point to design flaws on a higher level...
I don't think that DbC is confined to OOP really. After all, if you take all the hype out, DbC is nothing more than a method to monitor what happens at the entry and exit interfaces of functions/procedures. I've seen DbC stuff for ANSI-C, so it must be possible. One possible drawback in non-OO languages might be that strengthening contracts (as possible when inheriting class properties) might be a problem. Then again, PB interfaces allow for OO-ish programming, so it might be possible to implement this as well.
Come to think of it, that might be a nice project...
unit- or blackbox-testing certainly has its merits. Thanks for those links! I'd like to have DbC to instrument my functions/procedures on a somewhat lower level, to ascertain that:
- the contracts guarantee that the function/procedure works as intended
- error reports are as meaningful as possible and are pointing to the real cause of the error
- to automatically generate documentation about contracts, function interfaces in general, etc.
Only after ascertaining that the lower level stuff works as advertised, unit- or blackbox-testing becomes very meaningful, because errors found point to design flaws on a higher level...
I don't think that DbC is confined to OOP really. After all, if you take all the hype out, DbC is nothing more than a method to monitor what happens at the entry and exit interfaces of functions/procedures. I've seen DbC stuff for ANSI-C, so it must be possible. One possible drawback in non-OO languages might be that strengthening contracts (as possible when inheriting class properties) might be a problem. Then again, PB interfaces allow for OO-ish programming, so it might be possible to implement this as well.
Come to think of it, that might be a nice project...