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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Feb 9 18:05:56 UTC 2018


I understand that it can be but troubling to use a block with or: and: but
not xor:
Still I'm not fond of this change...

And indeed, we have the same laxist behavior for & and |.
See
https://stackoverflow.com/questions/47424242/understanding-weird-logical-operators-in-smalltalk/47425025#47425025

Didn't Eliot suggest something like:

Boolean>>xor: aBoolean
    ^self == aBoolean not

This way we don't accept aBlock but fail instantly at runtime because
messageNotUnderstood: #not...
Performance-wise, we still send a message (hopefully inlined soon with
sista).

Or maybe

True>>xor: aBoolean
    ^aBoolean ifTrue: [false] ifFalse: [self]

But before changing anything, consider that the right way to handle such
case
might better be to integrate QualityAssistant in the browser like in Pharo
See https://github.com/Uko/QualityAssistant


2018-02-09 18:31 GMT+01:00 Chris Cunningham <cunningham.cb at gmail.com>:

> #xor: is on the same plane as #| and #& - evaluate both sides and apply
>
> We also have #and: and #or: - evaluate receiver, and evaluate argument
> block if and only if necessary.
>
> I use #and: and #or: for speed purposes - and to avoid side effects
> (sometimes).
>
> I'm just curious - is there an equivalent symbol for xor similar to | and
> & that we could use?
>
> Also, before making this change to using blocks (if we do), we'd need to
> fix all users - probably also in the VMMaker packages.
>
> -cbc
>
> On Fri, Feb 9, 2018 at 9:18 AM, Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
>
>> On Fri, 9 Feb 2018, marcel.taeumel wrote:
>>
>> commits-2 wrote
>>>
>>>> A new version of Kernel was added to project The Inbox:
>>>> http://source.squeak.org/inbox/Kernel-fn.1151.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: Kernel-fn.1151
>>>> Author: fn
>>>> Time: 9 February 2018, 12:32:25.516883 pm
>>>> UUID: 9fb7df4b-6bf4-4af8-9c75-7496c2f0b517
>>>> Ancestors: Kernel-tonyg.1150
>>>>
>>>> For consistency: allow blocks to be passed into #xor: (see #or: and
>>>> #and:).
>>>>
>>>> =============== Diff against Kernel-tonyg.1150 ===============
>>>>
>>>> Item was changed:
>>>>   ----- Method: False>>xor: (in category 'logical operations') -----
>>>> + xor: alternativeBlock
>>>> - xor: aBoolean
>>>>         "Posted by Eliot Miranda to squeak-dev on 3/24/2009"
>>>>
>>>> +       ^alternativeBlock value!
>>>> -       ^aBoolean!
>>>>
>>>> Item was changed:
>>>>   ----- Method: True>>xor: (in category 'logical operations') -----
>>>> + xor: alternativeBlock
>>>> - xor: aBoolean
>>>>         "Posted by Eliot Miranda to squeak-dev on 3/24/2009"
>>>>
>>>> +       ^alternativeBlock value not!
>>>> -       ^aBoolean not!
>>>>
>>>
>>> Hey Nicolas,
>>>
>>> it seems that you had the intention to not allow "a xor: [b]" because,
>>> obviously, one does always have to check both operands for XOR. Yet,
>>> would
>>> it do any harm if we would allow "a xor: [b]"?
>>>
>>
>> Performance. Two fold: you create a block for no reason, because it will
>> always be evaluated right after its creation.
>> If there is no block, #value still has to be sent.
>>
>> Levente
>>
>>
>>
>>> Best,
>>> Marcel
>>>
>>>
>>>
>>> --
>>> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
>>>
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180209/6c687485/attachment.html>


More information about the Squeak-dev mailing list