> On 01 May 2015, at 10:17, Marcus Denker <[email protected]> wrote:
>
>
>> On 01 May 2015, at 10:10, stepharo <[email protected]> wrote:
>>
>> Clement
>>
>> thanks for the information. I thought about that.
>>
>> From a language perspective what you describe is plain bad. Implementation
>> should not creep in the language semantics.
>
> Yes, this is why we implemented the #mustBebooleanMagic.
>
> It now just works: when the optimised contruct is used on a non-boolean, we
> recompile the expression and execute is
> without optimization.
>
>> As a normal developer I do not want to know how I can redefine special
>> optimized selectors.
>
> Yes, you can… this was the whole point of the mustBebooleanMagic machinery.
Maybe I explain again.
Historically, Smalltalk makes interpretation fast by cheating: come selectors
are just hard coded into jumps.
(ifTrue:, or: …). But not always (e.g. not when the parameter is not a block).
This is very confusing. Therefore, we implemented a fall-back: when the VM
executes the optimised construct
on a non-boolean, it raises an exception. We catch that and just do what the
expression was supposed to do:
send the message.
This means now there is no problem anymore in overriding all these. The problem
has been fixed.
Marcus
