<div dir="ltr"><div class="GmSign">On Fri, Feb 9, 2018 at 8:30 PM Chris Cunningham <<a href="mailto:cunningham.cb@gmail.com">cunningham.cb@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 9, 2018 at 11:05 AM, Tony Garnock-Jones <span dir="ltr"><<a href="mailto:tonyg@leastfixedpoint.com" target="_blank">tonyg@leastfixedpoint.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 02/09/2018 06:47 PM, Nicolas Cellier wrote:<br>
> We also have a pair of binary messages that already works: ~= or even ~~<br>
<br>
</span>This is actually an excellent point.<br>
<br>
Perhaps the extra inefficiencies from the proposed new xor: definition<br>
that Levente identified are acceptable, given that performance-critical<br>
code can just use ~= or ~~?<br>
<br>
Being able to accept "a xor: b" as well as "a xor: [b]" seems like a win<br>
for consistency with the other spelled-out operators to me.<br>
<br></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div>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.)</div><div><br></div><div>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.  </div><div><br></div><div>Interesting that #and: and #or: are not there, either - why are they in "controlling"?</div><div><br></div><div>-cbc</div></div></div></div></blockquote><div><br></div><div>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?</div><div><br></div><div>Fabio</div></div></div>