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-ope...
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@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@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