[squeak-dev] The Inbox: Kernel-fn.1151.mcz

Fabio Niephaus lists at fniephaus.com
Sat Feb 10 16:33:44 UTC 2018


On Fri, Feb 9, 2018 at 8:30 PM Chris Cunningham <cunningham.cb at gmail.com>
wrote:

> On Fri, Feb 9, 2018 at 11:05 AM, Tony Garnock-Jones <
> tonyg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180210/82fc569c/attachment.html>


More information about the Squeak-dev mailing list