On Fri, Feb 9, 2018 at 8:30 PM Chris Cunningham <cunningham.cb@gmail.com> wrote:
On Fri, Feb 9, 2018 at 11:05 AM, Tony Garnock-Jones <tonyg@leastfixedpoint.com> wrote:
On 02/09/2018 06:47 PM, Nicolas Cellier wrote:
> We also have a pair of binary messages that already works: ~= or even ~~

This is actually an excellent point.

Perhaps the extra inefficiencies from the proposed new xor: definition
that Levente identified are acceptable, given that performance-critical
code can just use ~= or ~~?

Being able to accept "a xor: b" as well as "a xor: [b]" seems like a win
for consistency with the other spelled-out operators to me.

This was my original concern, too, but looking at Boolean, we have from ancient times the method #eqv: which expects a boolean as an argument.
It also is just another way to spell out == .  Just like xor: is another, more familiar way to say ~~ (which while truely the same, I would not have thought of.  Oh well.)

As an aside, we should move Boolean>>#xor: out of category "*Etoys-Squeakland-logical operations" and into just normal "logical operations" like #& and #eqv: and #xor: in the other booleans.  

Interesting that #and: and #or: are not there, either - why are they in "controlling"?

-cbc

Okay, so we have identified alternatives for performance-critical code (~= or ~~) and it does not seem necessary to update senders. Apart from Chris' side note, is there anything else that needs to be addressed before this can be merged?

Fabio