[squeak-dev] The Trunk: Kernel-cbc.1163.mcz
Chris Cunningham
cunningham.cb at gmail.com
Mon Mar 26 23:22:52 UTC 2018
That sounds reasonable.
On Mon, Mar 26, 2018 at 4:05 PM, Levente Uzonyi <leves at caesar.elte.hu>
wrote:
> Hi Chris,
>
> What if there's no real implementation in Boolean but
> #subclassResponibility?
>
> Levente
>
>
> On Mon, 26 Mar 2018, Chris Cunningham wrote:
>
> 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/6a23cdb3/attachment.html>
More information about the Squeak-dev
mailing list
|