<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
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.<br><br>[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.<br><br>> From: water@tunes.org<br>> Date: Thu, 26 Jul 2007 12:41:05 -0700<br>> To: squeak-dev@lists.squeakfoundation.org<br>> Subject: Re: Message Eating Null - article<br>> <br>> Hello,<br>> <br>> I would like to point out that both of these claims are unrealistic.<br>> <br>> Specifically, Keith's examples all use low-level control-flow <br>> messages like "notNil ifTrue: [" whereas non-novice Smalltalkers <br>> should be using "ifNotNil:" and "ifNotNilDo: [:obj |".<br>> <br>> The example would best be:<br>> <br>> widget setStringValue: (#(office phone lastNumberDialed asString) <br>> inject: person into: [:obj :sel | obj ifNotNil: [obj perform: sel]])<br>> <br>> without the message-eating Null pattern. Or if #perform: irks you, <br>> you can use:<br>> <br>> widget setStringValue: (person office ifNotNilDo: [:office | office <br>> phone ifNotNilDo: [:phone | phone lastNumberDialed ifNotNilDo: <br>> [:number | number asString]]])<br>> <br>> Like Keith, I find this a problem to have to write and maintain in <br>> code, but I'm not compelled to write long essays on it. I tend to <br>> think that chained message-sends represent a way in which distantly- <br>> related code can reach across protocols a bit too far. And Keith is <br>> being a bit unfair in that a several-page-long essay (with a really <br>> wide column justification width) will not be adequately rebutted in <br>> an email forum, thus keeping the discussion from balance.<br>> <br>> My own view is that message-eating null is usable in controlled <br>> circumstances, but that in general one cannot control the <br>> circumstances (you can't know who *won't* receive a null as a <br>> parameter, so code written without that in mind fails in strange <br>> ways) in Smalltalk-80.<br>> <br>> It is also worth pointing out that "message-eating null" most closely <br>> resembles the apposition of type T to NIL in Lisp, where one is the <br>> supertype of every type and the other is the subtype of every type. <br>> In Lisp, you do not interchange these, for good reason that I believe <br>> applies here but don't have time to gather evidence in support.<br>> <br>> I think his packages which use message-eating-null would be a lot <br>> more palatable if they didn't...<br>> <br>> On Jul 26, 2007, at 12:06 PM, Keith Hodges wrote:<br>> <br>> >> Yuck, I wouldn't do either of those. I would do:<br>> >><br>> >> widget setStringValue: #(office phone lastNumberDialed asString) <br>> >> inject: person into: [:obj :sel| o == nil ifTrue: [ nil ] ifFalse: <br>> >> [ obj sel ] ]<br>> > you would?<br>> ><br>> > To me the above looks as close to perl as smalltalk is hopefully <br>> > ever likely to get!<br>> ><br>> > ;-)<br>> <br>> That is disingenuous. Please use honest arguments.<br>> <br>> > Keith<br>> ><br>> > p.s. Someone once accused me of being a PL/1 programmer in a former <br>> > life.<br>> <br>> --<br>> -Brian<br>> http://briantrice.com<br>> <br>> <br><br /><hr />Local listings, incredible imagery, and driving directions - all in one place! <a href='http://maps.live.com/?wip=69&FORM=MGAC01' target='_new'>Find it!</a></body>
</html>