Re: [Pharo-project] Issue 1594 in pharo: refactor to use #ifNil:
Comment #11 on issue 1594 by patchi...@gmail.com: refactor to use #ifNil: http://code.google.com/p/pharo/issues/detail?id=1594 Uploaded to Inbox: SLICE-Issue-1594-Replace-equals-nil-and-not-equals-nil-with-isNil-and-notNil-FranciscoOrtizPenaloza.1 In pharo core image, Rewrite = nil to isNil Rewrite ~= nil to notNil
Comment #12 on issue 1594 by patchi...@gmail.com: refactor to use #ifNil: http://code.google.com/p/pharo/issues/detail?id=1594 It would be great to review this issue cause it's on Accepted state and i lots of ppl don't agree with it. Ocurrences of = nil or ~= nil were no more than ten but there're at least 800+ ocurrences of == nil or ~~ nil in PharoCore image so far.
Comment #13 on issue 1594 by marianopeck: refactor to use #ifNil: http://code.google.com/p/pharo/issues/detail?id=1594 i agree with the change
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. Cheers, Peter On Mon, 22 Nov 2010 21:08:23 +0100, <pharo@googlecode.com> wrote:
Comment #12 on issue 1594 by patchi...@gmail.com: refactor to use #ifNil: http://code.google.com/p/pharo/issues/detail?id=1594
It would be great to review this issue cause it's on Accepted state and i lots of ppl don't agree with it.
Ocurrences of = nil or ~= nil were no more than ten but there're at least 800+ ocurrences of == nil or ~~ nil in PharoCore image so far.
-- Peter van Rooijen Nijlring 83 5152 VJ Drunen m: 06-2854 2048
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:. Levente
Cheers, Peter
On Mon, 22 Nov 2010 21:08:23 +0100, <pharo@googlecode.com> wrote:
Comment #12 on issue 1594 by patchi...@gmail.com: refactor to use #ifNil: http://code.google.com/p/pharo/issues/detail?id=1594
It would be great to review this issue cause it's on Accepted state and i lots of ppl don't agree with it.
Ocurrences of = nil or ~= nil were no more than ten but there're at least 800+ ocurrences of == nil or ~~ nil in PharoCore image so far.
-- Peter van Rooijen Nijlring 83 5152 VJ Drunen m: 06-2854 2048
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
In a VM mail Andreas said: "Some set of incomplete process/delay/semaphore changes in Pharo. One of the problems with processes and delays is that this part of the system reacts very badly to random "cleaning". I.e., changing "foo == nil" to "foo isNil" can have dramatic effects (since it introduces a suspension point) with just the kind of weird issue you're seeing." I don't know if this is related to this issue. cheers mariano On Thu, Dec 2, 2010 at 10:50 PM, Peter van Rooijen <peter@vanrooijen.com>wrote:
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
participants (4)
-
Levente Uzonyi -
Mariano Martinez Peck -
Peter van Rooijen -
pharo＠googlecode.com