On Feb 8, 2004, at 12:11 AM, Ken Norris wrote:
We can plan exactly how and where we want to trap messages and provide callbacks that doublecheck for a proper response, i.e., one that falls within predetermined limits, can't we?
Formalize it and be able to explain it to managers and other programmers. Make a case study for runrev to post on their website!
I've been using runrev for a couple of years and I'm not writing code as well-planned as you describe. I'm still trying to get errorDialog working in my standalones, and figuring out why exception handling seems quirky sometimes.
I know someone who claims to write all his code so it's "mathematically tested to be correct" through some kind of elaborate unit testing (a C programmer actually, not runrev). That's one extreme. I don't know anyone else that has that kind of discipline or even if this person was really on the level.
With xtalks, and smalltalk, one just cannot know if a message is going to be accepted by an object until *runtime*. That is, run the app and see what happens. To an manager in charge of software for big $$ transactions, that translates into a craps shoot.
How do you ensure correctness in your app? Some languages have features like static typing, assertions, and robust exception handling, features that facilitate getting the correct, required behavior at runtime. How do you compensate for the absence of those features in your xtalk programming?
You've got xtalks at one end of the spectrum and and java, ada, eiffel, etc. at the other end of the spectrum. Just something to be aware of when you take runrev into corporate IT environments.
-- Alex Rice | Mindlube Software | http://mindlube.com
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
