Smalltalk › Pharo › Pharo Smalltalk Developers

Re: Issue 1594 in pharo: refactor to use #ifNil:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

pharo

Re: Issue 1594 in pharo: refactor to use #ifNil:

Comment #11 on issue 1594 by [hidden email]: 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

pharo

Re: Issue 1594 in pharo: refactor to use #ifNil:

Comment #12 on issue 1594 by [hidden email]: 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.

pharo

Re: Issue 1594 in pharo: refactor to use #ifNil:

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

Peter van Rooijen

Re: Issue 1594 in pharo: refactor to use #ifNil:

In reply to this post by pharo

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, <[hidden email]> wrote:

>
> Comment #12 on issue 1594 by [hidden email]: 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

Levente Uzonyi-2

Re: Issue 1594 in pharo: refactor to use #ifNil:

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, <[hidden email]> wrote:
>
>>
>> Comment #12 on issue 1594 by [hidden email]: 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
>

Peter van Rooijen

Re: Issue 1594 in pharo: refactor to use #ifNil:

On Thu, 02 Dec 2010 12:32:02 +0100, Levente Uzonyi <[hidden email]> 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

Mariano Martinez Peck

Re: Issue 1594 in pharo: refactor to use #ifNil:

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 <[hidden email]> wrote:

On Thu, 02 Dec 2010 12:32:02 +0100, Levente Uzonyi <[hidden email]> 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