#and:and:and: deprecated on 1.1, why?

>
> that methods is marked like "deprecated": 'Use self deprecated: 'Use and:
> instead'. '
>
> But curiosly the method #and:and:and:and: appears normal, without
> deprecation. That behavior is correct?
>
> Thanks
> --
> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2230786.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> But I don´t understand why the methods #and:and:and: AND #and:and:and:and:
> must be deprecateds... what is the equivalence now for that messages? is
> possible create a #&& and #|| messages?
>
> Regards
> --
> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231198.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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

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

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

>
> ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ]
>
>
> Regards
> --
> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> In general (but it often does not work :)) having a lot of conditions in OOP
> means that you are missing class to dispatch on then.
>
>> But then which is the equivalence to #and:and:and: when I have many
>> conditions?
>
> a and: [b] and: [c]
>
> if a and c do not have side effect that may change the condition are equivalent
> to
> a and: [ b and: [c]]
>
> so you have express what you want
>
>> Perhaps I will say a stupidity... but , not is valid the implementation of
>> #&& and #|| messages instead of #and:...  #or: .....?
>
>
> & and | are executing all their arguments while
>        true & error -> error
>        true and: [error] -> true but it is more costly
>
>
>>
>> ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ]
>>
>>
>> Regards
>> --
>> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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