Ned Konz wrote:
> 
> Jon K Anderson wrote:
> ?
> ? I like ifNotNil:.  It sounds clean to me:
> ?
> ?     this getThat
> ?         ifNotNil: [ :that | that doSomething ].
> 
> We already have ifNotNil: aBlock, which doesn't pass
> the non-nil object. So we have to come up with another name.
> The discussion was about the (existing) doIfNotNil: , as I recall.

After reading all the varied responses to this thread, it seems that there's no perfect solution to this. :-)

I definitely agree with Henrik's earlier point that it must include "ifNotNil" as a prefix, to make it clear that it's a specialization of ifNotNil:.  (e.g. "evaluate:" by itself is way too vague.)  I also agree with those who said that we don't want to draw attention to the block object itself.

For me, it's almost a tossup between ifNotNilIn:, ifNotNilDo:, or possibly just ifNotNil:.

I guess I would lean toward ifNotNilIn:, even though it's not very grammatical, it does fit in well with the existing concept of #in:, and is not misleading in any way.

ifNotNilDo: makes more sense grammatically, but it could cause confusion with the #do: convention for collections.  Especially since there's an argument in the block, just like a #do: block.  (E.g. the block in "aString do: [:ea | ea doSomething]" does something COMPETELY different from the block in "aString ifNotNilDo: [:ea | ea doSomething]".  Ouch.)

Playing devil's advocate, would it be so horrible to just re-use ifNotNil:, but allow zero or one arguments in the block?  IMO, it would be perfectly clear what was happening in the code, whether or not the block had an argument.  I guess you would need to have a check inside ifNotNil: to see whether the block contained an argument, though.  (Would there be implementation problems with this?)

Anyway, I very tentatively like ifNotNilIn: the most, or possibly ifNotNil:.

- Doug Way
  dway at riskmetrics.com
  RiskMetrics Group - Ann Arbor, MI
  http://www.riskmetrics.com