Dan Ingalls wrote:

> Since the end result is <someBlock> value: <some receiver>,
> the patterns should probably be
> 
> expr beValueFor: block
> expr ifNotNilBeValueFor: block
> or
> expr evaluate: block
> expr ifNotNilEvaluate: block
> 
> Has this all been hashed around in other Smalltalks with some reaonable
> outcome?

Don't know about other dialects, but consider how it will be used 95% of the
time, in guard clauses looking something like this:

x giveResult processMore

to guard against passing on nil you have to do:

intermediate _ x giveResult.
intermediate ifNotNil: [intermediate processMore]

but with this message you can write

x giveResult ifNotNilEvaluate: [:result | result processMore]

It's this type of statement that the message name should make conspicuous.

First of all, because of this typical use, I think the message should look
as much like a specialization of ifNotNil: as possible, ie. a suffix should
be added to ifNotNil, much like in how ifNil specializes ifTrue.

Secondly, the problem here is that Evaluate here refers to the block and
thus "draws the block to the foreground", when the block is really of no
interest, it's the contents of the block that matter. Consider if the
regular ifXxx: messages would draw attention to the blocks, which I normally
do not even think of as being there at all (and in the bytcodes they aren't
;-) :

ifTrueEvaluate: [self dothis; thenThat] ifFalseEvaluate: [self
someOtherStuff]

So we need a suffix that doesn't refer to the block but its contents. "Do"
is a very generic verb that unfortunately has been given a very specific,
non-standard meaning in Smalltalk. However, in "ifNotNilDo:" (to my mind at
least) the association with "do" messages (ie. iteration) is not that
strong, it functions more as the generic verb it is. However, I can see the
opinion going the other way as well, so "ifNotNilDo:" is my suggestion, but
I'm open to other generic suffix verbs.

Henrik