On 6 ao�t 2014, at 12:53, Cl�ment Bera <bera.clement@gmail.com> wrote:

What is interesting is to be able to reimplement #ifTrue:ifFalse: and co in any object in the system and to use it.

Now in practice it is difficult performance wise.

And why performance would be a problem? 
If ever it is used intensively and performance *become* a problem we can cache the deoptimized methods somewhere. 

As an experiment we overrided mustBeBooleanIn: so #ifTrue:ifFalse: and co would work on any object. However this hack is slow and interesting only for experiments IMO.
I asked in the bug report to add a setting... But no one answered and it was integrated. Marcus said we'll add a setting later.

So add a setting! 
I'm still confused about what the problem is here...
Because even if it's enabled by default it cannot break anything.


2014-08-06 8:31 GMT+02:00 stepharo <stepharo@free.fr>:
Ok thanks.
I do not see why this is interesting to have that.

https://pharo.fogbugz.com/default.asp?13779



On 5/8/14 21:24, Cl�ment Bera wrote:
Because someone activated the method "mustBeBooleanMagicIn:" by default whereas it was just a hack to experiment.

Basically you have an optimized message sent to a non boolean. For over a week now, in this case the code is executed as a DoIt with a non optimized message instead of raising the mustBeBoolean error.


2014-08-05 18:40 GMT+02:00 stepharo <stepharo@free.fr>:
Hi guys

Does anybody have an idea why when I open a transcript and recompile a method I get


UndefinedObject>>ExecuteUnOptimizedIn: (model is Undeclared)

UndefinedObject>>ExecuteUnOptimizedIn: (model is Undeclared)

UndefinedObject>>ExecuteUnOptimizedIn: (scroller is Undeclared)

Stef