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 <snoobabk@gmail.com>
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 < alejandroinfante91@gmail.com> 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 <sean@clipperadams.com>
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.