On Thu, 02 Dec 2010 12:32:02 +0100, Levente Uzonyi <[email protected]> wrote:
On Thu, 2 Dec 2010, Peter van Rooijen wrote:
I agree,
If you want to know if a object is the same object as
that designated by the expression nil, you use the message #==
(this message had guaranteed semantics since it can not be redefined).
If you want to know if the message ifNil: aBlock sent to the object
evaluates the block argument, you use the message #ifNil:
(which could do anything it has been defined to do
- at least, I would hope so!).
Those two uses are distinct and mean something different.
In theory yes, but the compiler also inlines #ifNil:, #ifNil:ifNotNil:,
#ifNotNil: and #ifNotNil:ifNil: if the arguments are literal blocks. So
in that case, they are equivalent with == nil ifTrue:/ifFalse:.
Thanks for explaining, I wasn't aware of that.
Seems like a really ugly hack to me.
Deciding semantics based on an argument type,
before the receiver type is known...extremely fishy.
Now, if the compiler inlined [...] ifNil: <something>
that would be a different matter, since the receiver
class is known at compile time, and it's not such
a big deal to require those semantics to be fixed.
Cheers, Peter
Levente
