May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by StÃ©phane Ducasse

tx! I found the traits bug :) Stef On May 26, 2010, at 1:38 PM, Lukas Renggli wrote: >> Not that I disagree with Stef in any way at all, but can you think of >> reasons - other than the historical ones - why #value:value:value: and >> friends are to be preferred over #valueWithArguments: ? > > They serve different purpose: > > - #valueWithArguments: is useful only if you have a collection of > arguments. If you have individual arguments you have to create a > collection first. > > - #value:value:value: is useful only if you have individual arguments. > If you have a collection of arguments you have to take them apart > first. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Lukas Renggli

> Not that I disagree with Stef in any way at all, but can you think of > reasons - other than the historical ones - why #value:value:value: and > friends are to be preferred over #valueWithArguments: ? They serve different purpose: - #valueWithArguments: is useful only if you have a collection of arguments. If you have individual arguments you have to create a collection first. - #value:value:value: is useful only if you have individual arguments. If you have a collection of arguments you have to take them apart first. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Peter Hugosson-Miller

Thanks, Lucas! I like nice clear concise lists of logical reasons like this :-) Not that I disagree with Stef in any way at all, but can you think of reasons - other than the historical ones - why #value:value:value: and friends are to be preferred over #valueWithArguments: ? -- Cheers, Peter On Wed, May 26, 2010 at 1:20 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > not right to me. I wanted to express the feeling that, for me, the one > > of the best things about Smalltalk is its readability in difference to > > C, which is very fast. The Â»new compiler optimizeÂ« both, anyway. > > - The "New Compiler" does not yet work. > > - The optimized #and:and:and: code never decompiled correctly. > > - The exact semantics of #and:and:and: is not clear without knowing > how it is implemented. > > - There are subtle semantic differences between "a and: [ b ] and: [ c > ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the > conditions have side-effects. > > - The #and:and:and: constructs are very confusing to newbies, I have > seen that numerous times. > > - The use of #and:and:and: doesn't shorten code. > > - #and:and:and: is not necessary from a language point of view. > > - And most important for me: #and:and:and: is incompatible with the > rest of the world. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by StÃ©phane Ducasse

thanks butcher :) You worked too much with philippe :))))) Stef On May 26, 2010, at 1:20 PM, Lukas Renggli wrote: >> not right to me. I wanted to express the feeling that, for me, the one >> of the best things about Smalltalk is its readability in difference to >> C, which is very fast. The Â»new compiler optimizeÂ« both, anyway. > > - The "New Compiler" does not yet work. > > - The optimized #and:and:and: code never decompiled correctly. > > - The exact semantics of #and:and:and: is not clear without knowing > how it is implemented. > > - There are subtle semantic differences between "a and: [ b ] and: [ c > ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the > conditions have side-effects. > > - The #and:and:and: constructs are very confusing to newbies, I have > seen that numerous times. > > - The use of #and:and:and: doesn't shorten code. > > - #and:and:and: is not necessary from a language point of view. > > - And most important for me: #and:and:and: is incompatible with the > rest of the world. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Lukas Renggli

> not right to me. I wanted to express the feeling that, for me, the one > of the best things about Smalltalk is its readability in difference to > C, which is very fast. The Â»new compiler optimizeÂ« both, anyway. - The "New Compiler" does not yet work. - The optimized #and:and:and: code never decompiled correctly. - The exact semantics of #and:and:and: is not clear without knowing how it is implemented. - There are subtle semantic differences between "a and: [ b ] and: [ c ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the conditions have side-effects. - The #and:and:and: constructs are very confusing to newbies, I have seen that numerous times. - The use of #and:and:and: doesn't shorten code. - #and:and:and: is not necessary from a language point of view. - And most important for me: #and:and:and: is incompatible with the rest of the world. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 26, 2010

Re: [Pharo-project] Using Pier to produce web sites

by StÃ©phane Ducasse

Thanks! Pier is often a bit too arcane to me :) > Hi Fernando: > > Some links that may be useful to you: > > - http://chapados.org/tutorials/pier-design-tutorial > - http://stblog.seasidehosting.st/seaside/pier/seccionpier (in Spanish) > > But you are right, Pier need desesperately good tutorials/howtos/documentation. > > Cheers. > > > 2010/5/25 Geert Claes <geert.wl.claes(a)gmail.com>: >> >> Maybe also post on the Pier mailing list >> http://forum.world.st/Magritte-Pier-and-Related-Tools-f115649.html >> (https://www.iam.unibe.ch/mailman/listinfo/smallwiki) >> -- >> View this message in context: http://forum.world.st/Using-Pier-to-produce-web-sites-tp2229712p2229969.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by StÃ©phane Ducasse

On May 26, 2010, at 12:31 PM, Richard Durr wrote: > Thanks for the response. I don't have a "real" argument â I wanted to > point out my bewilderment: > > Why is #value:value: and the like in the ansi protocol, when > #valueWithArguments: would be enough in any case? Of cause the answer > is semantically clarity, readability, expressiveness and convenience. > Doing something because it is "optimized by the compiler" instead of > choosing a less optimized, but clearer and more expressive way seems > not right to me. I wanted to express the feeling that, for me, the one > of the best things about Smalltalk is its readability in difference to > C, which is very fast. The Â»new compiler optimizeÂ« both, anyway. I understand now I think that and:and:and: is not nice nor necessary, especially since each time a message is optimized it means a lot more work for the decompiler and friends. It is different to value:value: since this is more historical. Now the main reason is to have a nice and clean core. Booleans do not really need and:and:and:. Stef > > > > On Wed, May 26, 2010 at 11:58 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> hi richard >> >>> WTF?! >> >> If you have a real argument we are really open to discussion. >> >>> These are the only reasons? >> I think that they are sufficient but again we are not saying that we know everything and that any solutions could not >> be rollback. We are doing and learning. >> Now having clean, lean and fast core classes are important. >> >> Because we could have and:or: or:and: and:and:or: and a couple of others in that case. >> >>> Why do we have #value:value:value: then? >> >> Because this is part of block protocol in the ANSI and because you cannot do it >> only with value: >> >> >>>> - and: is optimized by the compiler >>> We could use C, where "everything" is optimized by the compiler. >> >> I think that your point is out of scope but if you want you can use C. >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 26, 2010

Re: [Pharo-project] Using Pier to produce web sites

by GermÃ¡n Arduino

Hi Fernando: Some links that may be useful to you: - http://chapados.org/tutorials/pier-design-tutorial - http://stblog.seasidehosting.st/seaside/pier/seccionpier (in Spanish) But you are right, Pier need desesperately good tutorials/howtos/documentation. Cheers. 2010/5/25 Geert Claes <geert.wl.claes(a)gmail.com>: > > Maybe also post on the Pier mailing list > http://forum.world.st/Magritte-Pier-and-Related-Tools-f115649.html > (https://www.iam.unibe.ch/mailman/listinfo/smallwiki) > -- > View this message in context: http://forum.world.st/Using-Pier-to-produce-web-sites-tp2229712p2229969.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Richard Durr

Thanks for the response. I don't have a "real" argument â I wanted to point out my bewilderment: Why is #value:value: and the like in the ansi protocol, when #valueWithArguments: would be enough in any case? Of cause the answer is semantically clarity, readability, expressiveness and convenience. Doing something because it is "optimized by the compiler" instead of choosing a less optimized, but clearer and more expressive way seems not right to me. I wanted to express the feeling that, for me, the one of the best things about Smalltalk is its readability in difference to C, which is very fast. The Â»new compiler optimizeÂ« both, anyway. On Wed, May 26, 2010 at 11:58 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi richard > >> WTF?! > > If you have a real argument we are really open to discussion. > >> These are the only reasons? > I think that they are sufficient but again we are not saying that we know everything and that any solutions could not > be rollback. We are doing and learning. > Now having clean, lean and fast core classes are important. > > Because we could have and:or: or:and: and:and:or: and a couple of others in that case. > >> Why do we have #value:value:value: then? > > Because this is part of block protocol in the ANSI and because you cannot do it > only with value: > > >>> - and: is optimized by the compiler >> We could use C, where "everything" is optimized by the compiler. > > I think that your point is out of scope but if you want you can use C. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Henrik Johansen

On May 26, 2010, at 11:58 51AM, StÃ©phane Ducasse wrote: > hi richard > >> WTF?! > > If you have a real argument we are really open to discussion. > >> These are the only reasons? > I think that they are sufficient +1 > Because we could have and:or: or:and: and:and:or: and a couple of others in that case. No we could not :) Because of ambiguity: a and: (b or: c) is not the same as (a and: b) or: c Cheers, Henry

May 26, 2010