On Thu, 02 Dec 2010 12:32:02 +0100, Levente Uzonyi <leves@elte.hu> 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