This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: doesNotUnderstand: - The Dangers
Feed Title: David Buck - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/buck-rss.xml
Feed Description: Smalltalk can do that
Travis showed us how to do some cool things with doesNotUnderstand:. Although this is certainly an interesting use of DNU, I thought I'd mention the dangers of using a technique like this.
First, overriding DNU can be very dangerous. If you make any mistakes, your DNU handler may send a message which is not understood and get you into an infinite loop that will shut down your image. Fortunately, Travis did a good job implementing his handler and doesn't seem to have any infinite loops.
In addition consider these issues:
If you try browsing senders of with:with:with:with:with:with: you'll find none
The RBCodeHighlighting package will mark the message as undefined
The first time such a message is compiled, you will be told it doesn't exist and asked if you want to correct it
If there happens to be a method with:with:with:with:with:with: in some other class and you try to rename it to with:and:and:and:and:and:, the refactoring browser will kindly change all sends of with:with:with:with:with:with: into with:and:and:and:and:and: without realizing that there was actually more than one implementer and not all the senders should have been changed
The code critic will complain about a message sent but not implemented in any method that calls with:with:with:with:with:with:
It confuses the default class comment tool that tries to guess the class of the instance variables based on the messages sent to them
It's very difficult tracing the code through the debugger. I challenge you to put a halt just before a call to with:with:with:with:with:with: and use the debugger to step and send until you get to code that creates the collection (don't pull your hair out over this one)
It's not possible to put a breakpoint into with:with:with:with:with:with: - you'd have to use a conditional breakpoint in the DNU
Stack traces look suspicious with a DNU in their call stack
It can confuse people looking at code and can't figure out what it does using their normal techniques
It confuses the polymorphic inline caching and (in general) is much slower than the obvious alternative
In the long run, it takes people time to figure out tricks like this since it breaks their normal expectations and it confuses code that tries to do reflection.
To be fair, Travis' example is fairly mild and not as dangerous as some uses of DNU. This is, however, a tricky solution when there's a simple straightforward solution available. In my experience, tricky solutions are tricky to maintain especially when you have inexperienced developers on the team (the tricks can be hard to explain) and when you have tools that do reflection.
I don't mean to rain on Travis' parade, but I just wanted to point out some of the dangers of using tricky techniques especially when straightforward alternatives are available. I admit that there are more methods the conventional way, but each method is straightforward, easy to find and easy to reflect upon.
Previous Topic
