[ANSI-Smalltalk] Re: A list of interesting methods, ifNotNil:

[cstb]

At 01:39 AM 9/27/2008, Paulo Bonzini wrote:

>cstb wrote:
>...
>> 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].


Sorry - yes I use 3 of *those* 4 (#ifTrue:, #ifFalse:, #ifTrue:ifFalse:).

I was refering to *these* things (#ifNil:, #ifNotNil:, #ifNotNilAlwaysNeverDo:, etc...).

If we ONLY use the prefix 'if' for *those* original 4 branch methods,

1) I needn't retrain the motor-memory typeahead
   my fingers do all by themselves 'True:  ['.

2) I can "see" all the branches with a hidden #nil result,
     (i.e. all the one-armed #ifTrue: and #ifFalse: branches)
   without scanning, and without having to think about it.

   Whereas the 'exotic' forms all result in
     'self'
   for the unspecified case,
   so I like having an easily discernable difference
   in the naming pattern used.
 
But that's just me.


>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.


Ok - to each his own, I guess.

Appreciate the irony -
surprising, though, to hear that.

( Curiousity strikes.  Is it a collision
  of multiples, or no discernable meaning
  at all, when you read those (my) selectors?
)
 
Ah - I may once have had the same reaction,
if yours is likewise owing to the amgiguity
presented by one-argument keyword selectors,
viz-a-vis setters.  

I follow a fixed naming pattern
for all methods in the following categories:

  unary booleans    oneArmedGuards
  ==============    ==============
    isX         isX: [...]      
    notX                notX: [...]
                       orIfX: [...]

  unaryFlipFlops    oneArmedGuardWithReceiver           
  ==============    =========================
    beX                nonX: [:v| ...]
    beNotX

  getterForX        settersForX
  ===========       ===========
    x                  setX:
                       resetX:

which (also) disambiguates the setter case.

Most of which is stolen, of course.
Combined as above, it works well for me.
Stably so, for some time now.

And it took a long time to get to.
Perhaps I just got tired of looking
for a resolution, and settled on this.
But it seems a coherent whole.  FWIW.

   
>I think any decent standardization process of features that are already
>"in the wild" should look at existing code,


Absolutely.  And follow whatever precedent
can be unearthed, all other things being equal.


>and historically the methods
>were named #ifNil:ifNotNil:.


Yup.

It just happens I REALLY dislike those,
for the reasons I harped on above,
so it seems now is the time to
replace them, if ever.

Granted, this is the most trivial issue
of the Standard deliberations, on its face.

But it's also the selector-family
with the highest frequency of useage,
so even small nits can make for a large
annoyance.

And working through the 'process'
of resolving small issues
is probably best practiced
on small issues, and pounded
into grist, early on.
  

>They were in VA Smalltalk around ~1996
>with an "abt" prefix (like #abtIfNil:ifNotNil:).

  
Heaven's to mergatroid.
Triple-yucky-do-do, even.


>The "Do" part was added in Squeak only because they do not support
>variable arity blocks,


In any case, it seems an insufficient
not to mention terrible excuse
for co-opting something as
uber-ubiquitous as 'do'.


Cheers,

-Jim