On Tue, Jun 30, 2009 at 12:22 AM, Michael van der Gulik <span dir="ltr"><<a href="mailto:mikevdg@gmail.com">mikevdg@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br clear="all"><br>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.<br>
</blockquote></div><div><br></div><div>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.</div>
<div><br></div><div>In the abstract, semantically if I say something like:</div><div><br></div><div> anArbitraryObject someMethod ifTrue: aBlock.</div><div><br></div><div>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.</div>
<div><br></div><div>Similarly if I were to say something like:</div><div><br></div><div> ( anArbitraryObject + 1 ) < someLimit ifFalse: anotherBlock</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div>-- <br>-=-=-=-=-=-=-=-=-=-=- <a href="http://blog.dloh.org/">http://blog.dloh.org/</a><br>