and:and:and:...

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:

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 <[hidden email]> 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.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <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

On Fri, 1 Jan 2010, Randal L. Schwartz wrote:

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
> <[hidden email]> <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
>