In that specialSelectorArray the number that follows a selector is the number of arguments it takes? So if we want to take out the #== we should remove the "1" at the right of the selector right?
Also something really interesting (at least for me) is that "nil" is in that list, but I don't see "super" or "true". Also I thought that #new wasn't inlined, I'm (was) pretty sure I can override it. 2014/1/22 Carlo <[email protected]> > Not too sure which version of Pharo you’re using (image it’s 3) but Marcus > recently mentioned a similar issue. > > In Opal to remove the usage of #==, I removed it from the special selector > array in the method: > IRBytecodeGenerator class>>specialSelectorsArray > ^ #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 > #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 > #nextPut: 1 #atEnd 0 #== 1 nil 0 #blockCopy: 1 #value 0 #value: 1 #do: 1 > #new 0 #new: 1 #x 0 #y 0) > > Then I ran: > IRBytecodeGenerator initialize. > OpalCompiler recompileAll. > > > I looked in Pharo 3 image and tried the changes below: > OCASTTranslator class>>initialize > (removed line referring to the selector and then re-initialise) > and then > RBMessageNode>>isInlineIfNil > (removed the reference to the selector so not picked up as inlined) > > Then try recompile: OpalCompiler recompileAll. > Everything recompiles but then image dies so couldn’t test it so I might > be on wrong path ;) > > > On 23 Jan 2014, at 5:51 AM, Alejandro Infante < > [email protected]> wrote: > > Actually looking at the bytecode, it is inlined. I performed this little > experiment: > > MyClass>>foo > MyNullClass new ifNil: [ Transcript show: 'Nil';cr ] ifNotNil: [ > Transcript show: 'NotNil';cr ] > > So what it really does is > > MyNullClass new == nil > ifTrue: [ Transcript show: 'Nil';cr ] > ifFalse: [ Transcript show: 'NotNil';cr ]. > > (Well, the #ifTrue:ifFalse: is also inlined) > So actually subclassing UndefinedObject doesn't work either, because of > the #==. Also I think (I'm not completely sure about this), the #== doesn't > perform a lookup and the VM takes care of that, so there is no way to > change it's behavior by overriding it. > > About how to workaround... I have no idea =( > > Cheers, > Alejandro > > > 2014/1/22 Sean P. DeNigris <[email protected]> > >> I'm missing something here... >> I tried implementing: >> MyNullClass>>#ifNil: nilBlock ifNotNil: notNilBlock >> nilBlock value. >> But the notNilBlock is evaluated. I'm assuming it's being inlined. Is that >> right? How do I workaround? >> >> I also tried subclassing UndefinedObject, with the same result. >> >> Any ideas? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Null-Object-Pattern-tp4738574.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > >
