[squeak-dev] sane defaults and doesNotUnderstand: (was Future blah blah blah)

David Goehrig dave at nexttolast.com
Tue Jun 30 10:37:55 UTC 2009


On Tue, Jun 30, 2009 at 12:22 AM, Michael van der Gulik
<mikevdg at gmail.com>wrote:

>
>
> Changing the implementation of doesNotUnderstand: is a code smell. You're
> starting to play with voodoo and you need a *very* good reason to do it.
> Otherwise you'll have made yourself a very difficult application to debug.
>

In the spirit of communication, I'll explain why I consider the current
defaultHandler behavior of doesNotUnderstand:aMessage to be "broken".  My
Very Good Reason (TM) is based upon the principles of expectation.

In the abstract, semantically if I say something like:

    anArbitraryObject someMethod ifTrue: aBlock.

I am implicitly stating that I expect anArbitraryObject will return a
boolean when passed the message #someMethod.
 This expectation has nothing to do with the implementation of
anArbitraryObject, or with the meaning of #someMethod, only in the semantics
of how it fits within the overall structure of the statement.

Similarly if I were to say something like:

    ( anArbitraryObject + 1 ) < someLimit  ifFalse: anotherBlock

I am stating that I expect anArbitraryObject to return some sort of numeric
value, and that #+ will perform some sort of addition.  In this case the
result of #+ should also be something that can be compared using an ordering
#< message.

If any of these objects were to fall through to the defaultHandler, instead
of getting what I expected, I'll get a MessageNotUnderstood dialog, which
while incredibly helpful in debugging, doesn't actually "Do What I Mean".
 From a pure semantics point of view, I'd rather the system honor my intent
more so than confront me with implementation details.  MessageNotUnderstood
is an implementation detail, and does not correspond to the semantics of the
statement.  It is a literal  non sequitur.  This is doubly true in the case
of methods which merely test for a capability.  If the object doesn't
understand, then it clearly doesn't have the stated capability! Res ipso
loquitur.

So from my point of view, the current system behavior, while useful for
debugging, doesn't match the programmer's explicit semantics.  Additionally
there is an entire class of application, ones that consist of lots of
distributed and unique objects, in which the existing class based objects
become a de-optimization. These apps are typically only implementable by
rolling your own objects by hand, and attaching a custom
doesNotUnderstand:aMessage handler to each.  But that's a post for another
time.


-- 
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090630/3a5cd47e/attachment.htm


More information about the Squeak-dev mailing list