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

[cstb]

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

retains the very useful property

    <a visually unique prefix>.


Consider reconsidering (perhaps even try out)
these four related variations on the same theme:

                      *(written as what they do - not really implemented this way)

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])


#1 and #2:      The usual suspects, but without using 'if' in the name.
#3:             Like the proposed, but attrociously named, #ifNotNilDo: [:nonNil|...].
#4:            Like #1, but renamed for use as part of an answer or an assignment.

               >>outOnto: nillyStream
                   "
                     (self outOnto: nil) = 'theOutput'
                   "
                   | ws |
                   ws := nillyStream orIfNil: [String writeStream].
                   ws nextPutAll: 'theOutput'.
                   ^nillyStream orIfNil: [ws contents]



> ...
>
> Now, that discussion aside,
> what are we going to do from the point of
> view of the standard?  What are we after here?


An agreement on what to call these things,
so they can be implemented once by each vendor (and hopefuly inlined),
instead of once by each package/parcel/application/...
where they collide, conflict, and redundify.


-Jim