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