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

Jakob Reschke forums.jakob at resfarm.de
Sat Feb 10 18:05:25 UTC 2018


I am still wondering why one would want to use xor with a block in the
first place. The only purpose I can think of is that one does not
accidentally write broken code. But then again, you can always
misspell anything, get the types wrong, and you still need to test
your stuff, right? As Nicolas wrote, it could even be caught by an
automatic quality check in the future to shorten the time until
feedback.

Since short-circuiting evaluation seems to be the primary feature of
and: and or:, and I believe this is why they are in "controlling",
just like ifTrue: and ifFalse: are, why should xor: conform with them?
If it were not for Smalltalk's simple and uniform evaluation
semantics, we would not need the blocks for conjunction and
disjunction at all (you need to teach Smalltalk newcomers to use them
correctly, after all). So one has to understand that the blocks are
needed for conditional evaluation. Then the only reason why one would
want to apply that to xor: is that one mistakenly believes that it
might not always evaluate the right side, isn't it? If one believes
that xor: had to conform with and: and or: in their
technically-justified syntax usage ("oh I always have to use blocks to
the right of boolean operators"), then one might not have understood
the evaluation semantics yet and this patch would prevent one from
noticing it at this moment.

So the "prevent accidental breakage" argument might be valid enough to
merge this, but a linter should definitely point out the "misuse" as
soon as possible, IMHO.

2018-02-10 17:33 GMT+01:00 Fabio Niephaus <lists at fniephaus.com>:
> 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
>
>
>


More information about the Squeak-dev mailing list