I agree with you...I like the version that takes an argument.

I think it would be a shame, however, to have to test for the number of
arguments.  I would vote for just converting all senders over the test.

Another thought...how difficult would it be to change BlockContexts such
that they would ignore extra parameters?  Would there be a significant
performance penalty?  That way, you would always be allowed to use a block
that takes fewer arguments than actually supplied.  You wouldn't need to do
a test, and I think it would add nice flexibility.  Just thinking off the
top of my head...I haven't really considered whether or not it would be good
coding practice.

- Stephen

> -----Original Message-----
> From: Eric Arseneau [mailto:eat at huv.com]
> Sent: Friday, June 16, 2000 4:36 PM
> To: Squeak
> Subject: ifNotNil:
>
>
> In VA, the ifNotNil: accepts an argument, which is the receiver, why does
> Squeak not do this ?
>
> I like the VA version since it allows you to write blocks which are light
> weight, and also provides for cleaner code.  Example
>
> 	self someObject ifNotNil: [:object | object doSomething]
>
> instead of
>
> 	| temp |
> 	temp := self someObject.
> 	temp ifNotNil: [
> 		temp doSomething].
>
> The only way I can think of adding this is to do the following:
>
> ifNotNil: ifNotNilBlock
> 	"Evaluate the block, unless I'm == nil (q.v.)"
>
> 	ifNotNilBlock numArgs = 0 ifTrue: [
> 		^ifNotNilBlock value].
> 	^ifNotNilBlock value: self
>
> I hate code like this (note, this is done in
> Exception>>#handlerAction), but
> I find that the extra functionality from the ifNotNil: to be too
> useful.  I
> could always use another name, but then what would that name be ?
>
> Anybody have any thoughts on this ?