[squeak-dev] The Trunk: KernelTests-cbc.336.mcz

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


On Mon, Mar 26, 2018 at 7:26 AM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Chris,
>
> On Mar 25, 2018, at 9:16 PM, Chris Cunningham <cunningham.cb at gmail.com>
> wrote:
>
>
>
> On Mar 25, 2018 3:56 PM, "Eliot Miranda" <eliot.miranda at gmail.com> wrote:
>
> Hi Chris,
>
> On Sun, Mar 25, 2018 at 1:51 PM, <commits at source.squeak.org> wrote:
>
>> Chris Cunningham uploaded a new version of KernelTests to project The
>> Trunk:
>> http://source.squeak.org/trunk/KernelTests-cbc.336.mcz
>>
>> ==================== Summary ====================
>>
>> Name: KernelTests-cbc.336
>> Author: cbc
>> Time: 25 March 2018, 1:51:33.345291 pm
>> UUID: 6e6b91ac-d706-8f4d-bd60-1057109994cb
>> Ancestors: KernelTests-eem.335
>>
>> Test that new xor: takes blocks - but only those that result in
>> booleans.  Others raise errors.
>>
>> =============== Diff against KernelTests-eem.335 ===============
>>
>> Item was changed:
>>   ----- Method: FalseTest>>testXor (in category 'tests') -----
>>   testXor
>>         self assert: (false xor: true) = true.
>>         self assert: (false xor: false) = false.
>> +       self assert: (false xor: [true]) = true.
>> +       self assert: (false xor: [false]) = false.
>> +       self should: [false xor: [1]] raise: NonBooleanReceiver.!
>>
>
> Shouldn't "false xor: 1" also raise an error?
>
> Yes it will. I will put a check for that in I'd it makes sense.
>
> I don't see why "false xor: [1]" should raise NonBooleanReceiver
> specifically.
>
> That isn't ideal. It is a result of the implementation - ifTrue:ifFalse:
> is sent to the (value of the) argument which is then the "receiver" at that
> point and isn't an boolean.
>
>   It should raise an error, but whether [1] or 1 becomes the receiver
> internally to xor: seems to me an implementation detail.  Surely the
> receiver in "false xor: [1]" is false and that ids a boolean, so
> NonBooleanReceiver is an unintuitive error foBoolean.
>
> Yes but trapping this and making it more intuitive would make the xor:
> logic even more complex.
>
>
> You misunderstand.  The test case should test for Error, not for NonBooleanReceiver.
> Think of the tests as specifications, not precise descriptions of current
> behaviour.  Yes, the current /implementation/ raises NonBooleanReceiver
> (which is an error and hence meets the specification), but the
> specification requires only that aBoolean xor:  anything other than a
> Boolean or a valuable (something that understands value) that evaluates to
> a Boolean is an error.
>
> Thank you, you are of course correct.  This has been fixed (along with a
test for both [1] and 1).

>
>
>
>> -
>> -       self
>> -               should: [(false xor: [false])
>> -                       ifTrue: ["This should never be true, do not
>> signal an Error and let the test fail"]
>> -                       ifFalse: [self error: 'OK, this should be false,
>> raise an Error']]
>> -               raise: Error
>> -               description: 'a Block argument is not allowed. If it
>> were, answer would be false'.!
>>
>> Item was changed:
>>   ----- Method: TrueTest>>testXor (in category 'testing') -----
>>   testXor
>>         self assert: (true xor: true) = false.
>>         self assert: (true xor: false) = true.
>> +       self assert: (true xor: [true]) = false.
>> +       self assert: (true xor: [false]) = true.
>> +       self should: [true xor: [1]] raise: NonBooleanReceiver.!
>> -
>> -       self
>> -               should: [(true xor: [true])
>> -                       ifTrue: ["This should never be true, do not
>> signal an Error and let the test fail"]
>> -                       ifFalse: [self error: 'OK, this should be false,
>> raise an Error']]
>> -               raise: Error
>> -               description: 'a Block argument is not allowed. If it
>> were, answer would be false'.!
>>
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180326/d5427593/attachment.html>


More information about the Squeak-dev mailing list