[squeak-dev] The Trunk: Kernel-cbc.1163.mcz

Chris Cunningham cunningham.cb at gmail.com
Mon Mar 26 18:24:24 UTC 2018


Hi.

On Sun, Mar 25, 2018 at 3:23 PM, Levente Uzonyi <leves at caesar.elte.hu>
wrote:

> On Sun, 25 Mar 2018, Chris Cunningham wrote:
>
>
>>
>> On Mar 25, 2018 2:46 PM, "Levente Uzonyi" <leves at caesar.elte.hu> wrote:
>>       On Sun, 25 Mar 2018, commits at source.squeak.org wrote:
>>
>>             Chris Cunningham uploaded a new version of Kernel to project
>> The Trunk:
>>             http://source.squeak.org/trunk/Kernel-cbc.1163.mcz
>>
>>             ==================== Summary ====================
>>
>>             Name: Kernel-cbc.1163
>>             Author: cbc
>>             Time: 21 March 2018, 9:09:20.773568 pm
>>             UUID: 45d9dad8-7c81-034e-b578-b9ccd291cab6
>>             Ancestors: Kernel-dtl.1162, Kernel-fn.1152
>>
>>             Update #xor: to work with argument being a block as well.
>>
>>             =============== Diff against Kernel-dtl.1162 ===============
>>
>>             Item was added:
>>             + ----- Method: Boolean>>xor: (in category 'logical
>> operations') -----
>>             + xor: aBoolean +       "Exclusive OR. Answer true if the
>> receiver is not equivalent to aBoolean."
>>             + +     ^(self == aBoolean) not!
>>
>>
>> Why not just
>>
>>         ^self ~~ aBoolean
>>
>> Because that lets you xor between Boolean and other a
>> Odd stuff. Meaning bugs can creep in without any errors being raised.
>>
>
> Am I missing something? Is there a case when [a~~b] and [(a==b)not] yield
> different results where a and b can be any object?
>
> You are not missing anything - I misunderstood your question the first
time around (which is why my response was garbage - at least, this time
why).

Yes, that could be fixed, and would provide a clue as to an alternative
fast version.

However, I wonder what a right fix would be?  The subclasses now make sure
the arguments equate to a boolean - and it would be weird to have the super
class not care about that.  On the other hand, having the super class use
~~ would give the pointer of how to make it really fast - and a more
generic explanation.  Hmm.

Maybe I could switch it around, and add a few comments about how this isn't
'safe' but is fast, and also take the opportunity to make better variable
names in the subclasses.

-cbc

> Also, this method is overridden in all subclasses, isn't it?
>
> Yes ~~ is faster - but xor: is already fast.
>>
>
> It's not about speed. It's about unnecessary complexity.
>
> Levente
>
>
>
>>       ?
>>
>>
>>             Item was changed:
>>              ----- Method: False>>xor: (in category 'logical operations')
>> -----
>>              xor: aBoolean
>>             +       "aBoolean is either a boolean, or an object who's
>> #value returns a boolean (usually a block)."
>>             +       ^aBoolean value ifTrue: [ true ] ifFalse: [ false ]!
>>
>>
>> I think the parameter should have a better name, because the #value send
>> doesn't make much sense when you read the code.
>>
>> I guess so.
>>
>>       Levente
>>
>>             -       "Posted by Eliot Miranda to squeak-dev on 3/24/2009"
>>             - -     ^aBoolean!
>>
>>             Item was changed:
>>              ----- Method: True>>xor: (in category 'logical operations')
>> -----
>>              xor: aBoolean
>>             +       "aBoolean is either a boolean, or an object who's
>> #value returns a boolean (usually a block)."
>>             +       ^aBoolean value ifTrue: [ false ] ifFalse: [ true ]!
>>             -       "Posted by Eliot Miranda to squeak-dev on 3/24/2009"
>>             - -     ^aBoolean not!
>>
>>
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180326/b9547a53/attachment-0001.html>


More information about the Squeak-dev mailing list