[Pharo-project] why #ifNotNil: accepts parameter?
Hi, I'm trying to understand why pharo modifies squeak behavior of ifNotNil: and introduces the optional parameter... is there a reason? Cheers, Esteban
I'm trying to understand why pharo modifies squeak behavior of ifNotNil: and introduces the optional parameter... is there a reason?
Squeak for that matter is incompatible with all other existing Smalltalk implementations. Luckily that was changed in Pharo. the compiler can easily figure out if an argument needs to be passed into the block or not. There is really no need for all these ugly #...Do: methods. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On 2009-01-27 11:05:49 -0200, Lukas Renggli <renggli@gmail.com> said:
I'm trying to understand why pharo modifies squeak behavior of ifNotNil: and introduces the optional parameter... is there a reason?
Squeak for that matter is incompatible with all other existing Smalltalk implementations. Luckily that was changed in Pharo. the compiler can easily figure out if an argument needs to be passed into the block or not. There is really no need for all these ugly #...Do: methods.
Lukas
Yes, I understand... but now I have a compatibility issue with OB-Tools (works on pharo, doesn't works on squeak) :( Anyway, I understand :) Cheers, Esteban
I found this blog entry really nice on this specific question. http://blog.3plus4.org/2007/04/ On Jan 27, 2009, at 1:44 PM, Esteban Lorenzano wrote:
Hi, I'm trying to understand why pharo modifies squeak behavior of ifNotNil: and introduces the optional parameter... is there a reason?
Cheers, Esteban
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Very interesting stef, thanks a lot... but now, I'm not sure of what I did with OB-Tools (I just replace ifNotNil: [ :blah | ... ] with ifNotNilDo: [ :blah | ... ]... I understand why the first version of ifNotNil: is done like that in pharo... but what I do with compatibility? will pharo still support ifNotNilDo:? And, I also agree with lukas. blahDo: is ugly, if you have an elegant solution... but, what I have to do with OB-Tools? I replace methods (like before) or better I create a package OB-Tools-Squeak with extensions for Squeak? I know... this is hardly a "pharo issue", but maybe can provide pharo developers of clues of what to do if they are trying to keep compatibiity (I know, that's not a pharo goal -compatibility-, but sometimes may be necessary). Cheers, Esteban On 2009-01-27 13:09:30 -0200, Stéphane Ducasse <stephane.ducasse@inria.fr> said:
I found this blog entry really nice on this specific question.
http://blog.3plus4.org/2007/04/
On Jan 27, 2009, at 1:44 PM, Esteban Lorenzano wrote:
Hi, I'm trying to understand why pharo modifies squeak behavior of ifNotNil: and introduces the optional parameter... is there a reason?
Cheers, Esteban
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
And, I also agree with lukas. blahDo: is ugly, if you have an elegant solution... but, what I have to do with OB-Tools? I replace methods (like before) or better I create a package OB-Tools-Squeak with extensions for Squeak?
I guess the best is to follow the Seaside coding conventions (http://www.seaside.st/community/conventions) for cross platform code like OB-Tools. You might also want to use Slime (http://www.lukas-renggli.ch/blog/slime), because it automatically fixes simple issues like the #ifNotNilDo: thing. Also keep in mind that OB-Tools is supposed to run on GemStone , so better not use #ifNotNilDo:. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Jan 27, 2009, at 5:04 PM, Esteban Lorenzano wrote:
Very interesting stef, thanks a lot...
but now, I'm not sure of what I did with OB-Tools (I just replace ifNotNil: [ :blah | ... ] with ifNotNilDo: [ :blah | ... ]... I understand why the first version of ifNotNil: is done like that in pharo... but what I do with compatibility? will pharo still support ifNotNilDo:? And, I also agree with lukas. blahDo: is ugly, if you have an elegant solution... but, what I have to do with OB-Tools? I replace methods (like before) or better I create a package OB-Tools-Squeak with extensions for Squeak?
I know... this is hardly a "pharo issue", but maybe can provide pharo developers of clues of what to do if they are trying to keep compatibiity (I know, that's not a pharo goal -compatibility-, but sometimes may be necessary).
May be package extensions separately. By accident have you seen the dates of the fixes proposed by vassili 2007 this is not that long compared to the changes of compiled method that we are waiting since at least 2001. So this is why changing is important. But changing for better :) Stef
Cheers, Esteban
On 2009-01-27 13:09:30 -0200, Stéphane Ducasse <stephane.ducasse@inria.fr> said:
I found this blog entry really nice on this specific question.
http://blog.3plus4.org/2007/04/
On Jan 27, 2009, at 1:44 PM, Esteban Lorenzano wrote:
Hi, I'm trying to understand why pharo modifies squeak behavior of ifNotNil: and introduces the optional parameter... is there a reason?
Cheers, Esteban
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
That's a good choice... I will follow seaside conventions then :) Cheers, Esteban On 2009-01-27 14:40:16 -0200, Lukas Renggli <renggli@gmail.com> said:
And, I also agree with lukas. blahDo: is ugly, if you have an elegant solution... but, what I have to do with OB-Tools? I replace methods (like before) or better I create a package OB-Tools-Squeak with extensions for Squeak?
I guess the best is to follow the Seaside coding conventions (http://www.seaside.st/community/conventions) for cross platform code like OB-Tools. You might also want to use Slime (http://www.lu
----- "Lukas Renggli" <renggli@gmail.com> wrote: | > And, I also agree with lukas. blahDo: is ugly, if you have an | elegant | > solution... but, what I have to do with OB-Tools? I replace methods | > (like before) or better I create a package OB-Tools-Squeak with | > extensions for Squeak? | | I guess the best is to follow the Seaside coding conventions | (http://www.seaside.st/community/conventions) for cross platform code | like OB-Tools. You might also want to use Slime | (http://www.lukas-renggli.ch/blog/slime), because it automatically | fixes simple issues like the #ifNotNilDo: thing. Also keep in mind | that OB-Tools is supposed to run on GemStone , so better not use | #ifNotNilDo:. I introduced this incompatibility in my recent bugfixes for the debugger in OB-Tools, so the code in question is in a Squeak/Pharo specific chunk... Since I work in GemStone most of the time, I wasn't aware of the differences #ifNotNil:...:) You'll see more '== nil' in my code from now on:) Dale
On 27.01.2009, at 17:56, Stéphane Ducasse wrote:
On Jan 27, 2009, at 5:04 PM, Esteban Lorenzano wrote:
Very interesting stef, thanks a lot...
but now, I'm not sure of what I did with OB-Tools (I just replace ifNotNil: [ :blah | ... ] with ifNotNilDo: [ :blah | ... ]... I understand why the first version of ifNotNil: is done like that in pharo... but what I do with compatibility? will pharo still support ifNotNilDo:? And, I also agree with lukas. blahDo: is ugly, if you have an elegant solution... but, what I have to do with OB-Tools? I replace methods (like before) or better I create a package OB-Tools-Squeak with extensions for Squeak?
I know... this is hardly a "pharo issue", but maybe can provide pharo developers of clues of what to do if they are trying to keep compatibiity (I know, that's not a pharo goal -compatibility-, but sometimes may be necessary).
May be package extensions separately. By accident have you seen the dates of the fixes proposed by vassili 2007 this is not that long compared to the changes of compiled method that we are waiting since at least 2001.
Wasn't that more like 1998? Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
On Tue, Jan 27, 2009 at 7:41 PM, Dale Henrichs <dale.henrichs@gemstone.com> wrote:
You'll see more '== nil' in my code from now on:)
#isNil? -- Damien Cassou http://damiencassou.seasidehosting.st
participants (6)
-
Dale Henrichs -
Damien Cassou -
Esteban Lorenzano -
Lukas Renggli -
Marcus Denker -
Stéphane Ducasse