On Nov 22, 2006, at 4:29 PM, Brendan Murphy wrote:
Charles Yeomans wrote:
There is no "traditional usage of the assert" in REALbasic. There
may be such in C. As for the correct usage of assertions, that's a
little trickier than many people seem to realize.
What I mean by traditional is how it is implemented in that the
developer has complete control if the asserts get compiled in
without having to surround assert statements with #if statements.
My point of view comes from the traditional implementation from
over the years it has been implemented in other systems. Joe's
point of view comes from a book he read which takes an different
reactionary view which I believe is based on faulty reasoning.
I think Joe also has extensive programming experience on complex
multiple-developer projects using multiple languages, at least one of
which he helped to implement; perhaps that has also informed his
opinions. What book is it that you believe is based on faulty
reasoning? Maybe I've read it too.
It's also not clear to me how RS could write this Assert method for
you. I'm quite sure they don't know what I want it to do, since in
different projects I may have it do different things. One client
wants
it to display a message box; another wants it to use
System.DebugLog; a
third wants the error written to their own log file. If they
were to
implement it, what makes you think they would choose whatever
functionality you happen to prefer?
It is simple, the assert method calls an event and the developer
handles it there.
Uh, calls an event where? The only reasonable place for such an
event would be the Application object. The result of this would be
that the Application object would be coupled to the error-handling of
every object that uses an assertion. This sounds like a recipe for
disaster.
This is not a recipe for disaster. The code for the assertion
method is generated by the compiler and the assertion test is
executed by that generated code. If an error is detected, then
the appropriate information is sent off to the developer event. In
that event the user can do whatever is appropriate for that
application to respond to the event (throw an exception, post a
dialog, log the event, etc.).
And where does this "developer event" live? If it's outside the
class, then I fail to see how undesirable coupling is unavoidable.
When used correctly, an assertion tests code correctness. An
assertion failure is probably not something that the assertion method
itself can handle, so the correct action is to raise an exception.
What I am suggesting is a mechanism to handle the different needs
of when the assertion is triggered. If the developer determines
his application needs to throw an exception, he can do so. Joe's
point was he couldn't see a way to generically handle the
different needs. I have provided a viable solution. This isn't
rocket science.
The simplest, and my opinion correct, solution would be for a failed
assertion to raise an exception. Assertions aren't for error-
handling; they are for error-generating.
Joe you were part of the problem at RS when you worked there
because of this misguided attitude regarding asserts. Since you
don't work there any more, perhaps things have changed on this
issue. If RS's stance reflects your attitude upon the issue, then
we will never get a proper assert implementation simply because
they wish to enforce a particular development style upon us for
our own good.
As far as I can tell, RS' stance usually reflects Geoff Perlman's
attitude. Perhaps you should take it up with him. Your own attitude
regarding assertions would certainly be seen as misguided by some.
With what I am suggesting, everyone can have their cake and eat it
too since it can accommodate both philosophies. With what Joe is
suggesting, his development philosophy is forced on all of us.
Which is more misguided? In order to make asserts work properly,
we need help from RS to generate a zero foot print in the code
when we turn them off.
With what Joe is suggesting, each developer has to implement his own
ideas. You're the one pounding the metaphorical table for what you
believe to be the "traditional" way of doing things.
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
