Happy new year squeakers!
A question of style to start: I know, nested conditions c1 and: [c2 and: [c3]] are sometimes harder to read than separated c1 and: [c2] and: [c3] I personally don't feel the former as a problem, especially with good indentations and shout. The main difference is that the later won't be inlined and will thus be slower - unless Cog change the deal?
There is another difference in favor of the later: it produces shorter jump and thus can compile longer methods. But that is a bad argument... Methods should better be short.
IMO these squeakisms have too low a value and should be deprecated. Thoughts?
Nicolas
On Fri, 1 Jan 2010, Nicolas Cellier wrote:
Happy new year squeakers!
A question of style to start: I know, nested conditions c1 and: [c2 and: [c3]] are sometimes harder to read than separated c1 and: [c2] and: [c3] I personally don't feel the former as a problem, especially with good indentations and shout. The main difference is that the later won't be inlined and will thus be slower - unless Cog change the deal?
There is another difference in favor of the later: it produces shorter jump and thus can compile longer methods. But that is a bad argument... Methods should better be short.
IMO these squeakisms have too low a value and should be deprecated. Thoughts?
I agree. I also prefer #and: and #or: against #& and #|, mainly because of better performance. These two are in the ANSI standard so we shouldn't remove them, but replacing their sends with #and: and #or: in the trunk sounds like a good idea.
Levente
Nicolas
"Levente" == Levente Uzonyi leves@elte.hu writes:
Levente> I agree. I also prefer #and: and #or: against #& and #|, mainly Levente> because of better performance. These two are in the ANSI standard so Levente> we shouldn't remove them, but replacing their sends with #and: and Levente> #or: in the trunk sounds like a good idea.
No. The semantics of #and: and #or: guarantee short-circuit evaluation, while #& and #| always evaluates the argument. You can't just trade one for the other.
On Fri, 1 Jan 2010, Randal L. Schwartz wrote:
"Levente" == Levente Uzonyi leves@elte.hu writes:
Levente> I agree. I also prefer #and: and #or: against #& and #|, mainly Levente> because of better performance. These two are in the ANSI standard so Levente> we shouldn't remove them, but replacing their sends with #and: and Levente> #or: in the trunk sounds like a good idea.
No. The semantics of #and: and #or: guarantee short-circuit evaluation, while #& and #| always evaluates the argument. You can't just trade one for the other.
Not in theory, but in practice. :) In worst case replacing #& with #and: could suppress side effects of the argument, but users of #& are unlikely to cause side effects intentionally, though these can be checked one-by-one and the calculations (which cause the side effects) can be extracted. It's unlikely that such case exists where this extraction is necessary.
I quickly looked at ~50 senders of #& and #| and all of them were written with the purpose to omit the parentheses around the logical expression:
foo & bar baz ifTrue: [ ... ] (foo and: [ bar baz ]) ifTrue: [ ... ]
Levente
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
squeak-dev@lists.squeakfoundation.org
-
Levente Uzonyi -
merlyn＠stonehenge.com -
Nicolas Cellier