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 > <[email protected]> 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
