[ANSI-Smalltalk] Re: A list of interesting methods, ifNotNil:
Andres Valloud
andres.valloud at gmail.com
Sat Sep 27 09:59:32 BST 2008
What I see from this, going to a more meta discussion, is the
following. I think it would be a good idea to get some clarification
in our operating procedure --- at least from my POV, perhaps it's been
clear to you guys all along and I am being an idiot.
For me, the thing with ifNilDo: is that, while I recognize that it's
in wide use across many Smalltalks, I feel some hesitation in
christening it as a standard because I do not think it's good
technique. But that's just my opinion, of course, so here's the
clarification part. What are we going to do when this happens?
a) we merely collect what is de-facto standard Smalltalk usage and document it,
b) we do a) and promote them to standard status after some review to
make sure we do not standardize things like 3 $% 5 to mean 3 + 5
(extreme example just for the sake of illustration only).
If we go the b) route, how do we determine what constitutes "proper"
Smalltalk? For example, in this case I do have an opinion but it's
not a show stopper kind of concern. But what if the day of tomorrow
one of us does have such a reservation? We vote and that's it, right?
Assuming that we go the b) route with a vote as a binding resolution
mechanism, then I have not much more to say re: ifNilDo: etc and I am
happy with the a) part of b) above.
Andres.
On Sat, Sep 27, 2008 at 1:39 AM, Paolo Bonzini <bonzini at gnu.org> wrote:
> cstb wrote:
>> At 08:57 PM 9/25/2008, Andres wrote:
>>> ...
>>> I try not to use ifNil:/ifNotNil: as a conditional branch control
>>> message because they do not behave the same as ifTrue:ifFalse:.
>>
>>
>> Agreed.
>>
>> For that same reason, and several others,
>> I'd rather we did *not* name these things
>> using variations of the pattern
>>
>> #if{condition}:
>>
>> so that the sequence
>>
>> space-$i-$f
>
> So you don't use ifTrue:ifFalse: to do
>
> x := foo ifTrue: [1] ifFalse: [0].
>
> ?
>
> It is also ironic that I find these names
>
>> 1) >>isNil: a0block (^self isNil ifTrue: [a0block value] ifFalse: [self])
>> 2) >>notNil: a0block (^self isNil ifTrue: [nil] ifFalse: [a0block value])
>> 3) >>nonNil: a1block (^self isNil ifTrue: [nil] ifFalse: [a1block value: self])
>> 4) >>orIfNil: a0block (^self isNil ifTrue: [a0block value] ifFalse: [self])
>
> to be totally non-intention revealing except the fourth -- the only one
> which includes "If" in its name.
>
> I think any decent standardization process of features that are already
> "in the wild" should look at existing code, and historically the methods
> were named #ifNil:ifNotNil:. They were in VA Smalltalk around ~1996
> with an "abt" prefix (like #abtIfNil:ifNotNil:).
>
> The "Do" part was added in Squeak only because they do not support
> variable arity blocks, which could be added contextually.
>
> Paolo
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
More information about the ANSI-Smalltalk
mailing list