I am not decided against the generalized null pattern just yet [1].  I just wanted to point out that no one is going to put 5 temps in a row like that.  The exception might be more common but I never see it.[1] I am not going to say it's bad, nor am I convinced it is a sure win.  Personally I can't recall a single time I have needed something like this.  I do tend to chain messages often, but I guess I only do that when I don't expect a nil.  If one comes up I want to see it right then to track it down.  But perhaps in other domains then I have been programming in so far it would come up more.  At any rate I'm glad it's out there to try out if I need it.  Thanks for that Keith.> From: water at tunes.org> Date: Thu, 26 Jul 2007 12:41:05 -0700> To: squeak-dev at lists.squeakfoundation.org> Subject: Re: Message Eating Null - article> > Hello,> > I would like to point out that both of these claims are unrealistic.> > Specifically, Keith's examples all use low-level control-flow  > messages like "notNil ifTrue: [" whereas non-novice Smalltalkers  > should be using "ifNotNil:" and "ifNotNilDo: [:obj |".> > The example would best be:> > widget setStringValue: (#(office phone lastNumberDialed asString)  > inject: person into: [:obj :sel | obj ifNotNil: [obj perform: sel]])> > without the message-eating Null pattern. Or if #perform: irks you,  > you can use:> > widget setStringValue: (person office ifNotNilDo: [:office | office  > phone ifNotNilDo: [:phone | phone lastNumberDialed ifNotNilDo:  > [:number | number asString]]])> > Like Keith, I find this a problem to have to write and maintain in  > code, but I'm not compelled to write long essays on it. I tend to  > think that chained message-sends represent a way in which distantly- > related code can reach across protocols a bit too far. And Keith is  > being a bit unfair in that a several-page-long essay (with a really  > wide column justification width) will not be adequately rebutted in  > an email forum, thus keeping the discussion from balance.> > My own view is that message-eating null is usable in controlled  > circumstances, but that in general one cannot control the  > circumstances (you can't know who *won't* receive a null as a  > parameter, so code written without that in mind fails in strange  > ways) in Smalltalk-80.> > It is also worth pointing out that "message-eating null" most closely  > resembles the apposition of type T to NIL in Lisp, where one is the  > supertype of every type and the other is the subtype of every type.  > In Lisp, you do not interchange these, for good reason that I believe  > applies here but don't have time to gather evidence in support.> > I think his packages which use message-eating-null would be a lot  > more palatable if they didn't...> > On Jul 26, 2007, at 12:06 PM, Keith Hodges wrote:> > >> Yuck, I wouldn't do either of those.  I would do:> >>> >> widget setStringValue: #(office phone lastNumberDialed asString)  > >> inject: person into: [:obj :sel| o == nil ifTrue: [ nil ] ifFalse:  > >> [ obj sel ] ]> > you would?> >> > To me the above looks as close to perl as smalltalk is hopefully  > > ever likely to get!> >> > ;-)> > That is disingenuous. Please use honest arguments.> > > Keith> >> > p.s. Someone once accused me of being a PL/1 programmer in a former  > > life.> > --> -Brian> http://briantrice.com> > 
_________________________________________________________________
Local listings, incredible imagery, and driving directions - all in one place! Find it!
http://maps.live.com/?wip=69&FORM=MGAC01
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070726/1b15f3be/attachment.htm