ifNotNil:
Stephen Pair
spair at advantive.com
Fri Jun 16 19:19:06 UTC 2000
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 ?
More information about the Squeak-dev
mailing list
|