On 6 août 2014, at 12:53, Clément Bera <[email protected]> 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 <[email protected]>: > 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 <[email protected]>: >> 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 >> >> > >
