2015-05-01 11:58 GMT+02:00 Thierry Goubier <[email protected]>:
> Le 01/05/2015 11:50, Marcus Denker a écrit : > >> >> On 01 May 2015, at 11:48, stepharo <[email protected]> wrote: >>> >>> >>> >>> >>>> To make the whole thing easier to understand we need to distinguish the >>>> two bugs. >>>> >>>> 1) or: is somehow special. No, it is not. We fixed that, but the fix >>>> was broken. >>>> >>> This is wrong. They are special for non compiler developer. I explain why below. > See my other mail. >>> I would add two different kind of rules to help people and slow the use >>> of redefinition of special selectors. >>> >> >> >> I do not understand why. >> > > I side with Marcus there. Why? > Why ? Because you can't debug them normally. If they're executed normally, you cannot step into sends using these selectors on the contrary to any other send because they are inlined, which is light because most of the time you don't want to step into these selectors. If they're executed on non boolean, the debugger shows the whole #mustBeBoolean, #mustBeBooleanIn: and #ExecuteUnoptimizedIn: stack of noise, and that's assuming the ExecuteUnoptimizedIn: would work in any case without errors. They are very special because they can't be debugged as other selectors. And I'm not talking about rare cases which make these selectors only slightly special, like for example where you run out of literals in a method, the method is not shown in the list of senders of the special selectors it uses. Debugging has already become much harder now that we have slots: the debugger highlights an instance variable in a frame whereas there are frames below, so you now have to understand slots to debug code. It is not possible to make the debugger compliant with slots because the debugger has access only to the bottom 20 frames of the active stack for other good reasons such as a very deep recursive stack, and if the instance variable access with a slot is not in these bottom 20 frames, the debugger can't detect it. Now in addition, you're telling me that for some selectors in specific cases instead of the regular stack I will have #mustBeBoolean, #mustBeBooleanIn: and #ExecuteUnoptimizedIn: inserted into the stack. So to debug code, you have to understand this hack too. What is the next step ? Do you want the debugger to show a stack mainly unrelated to what the programmer wrote that only compiler developers can understand ? Are we also in Pharo in the philosophy where we don't care about how bad is the debugger ? I agree with Stef that there should be a warning telling you that shouldn't override such selectors if you don't know what you are doing. Btw control flow selectors are not the only special selectors. You cannot override #== anywhere in Pharo too. > You now have a compiler which does not make those selectors special, and > you want to keep them special? > > They're kept special in any case, for compiler developers and non compiler developers. We do not have a compiler and a VM that do not make those selectors special (Yes, this is not only a compiler problem, it's a VM + compiler problem). As far as I know, only the Self VMs and compilers do not keep those selectors special. > Thierry > > >> Marcus >> >> >> > >
