So I tried and it worked.
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.
Then in my example:
A>>==
^ true
a := A new.
b := A new.
a == b answered true, so it worked.
I don't like all these messages with no lookup. I don't even know if this
permits to earn performance now that we have inline caches.
@Frank Shearar
Just a detail, #timesRepeat: is not inlined any more by default in Pharo
3.0 because there were conflicts with a stream library. Anyway it didn't
provide a lot of performance (just removed 1 indirection).
2014/1/6 Frank Shearar <[email protected]>
> On 6 January 2014 11:11, Nicolai Hess <[email protected]> wrote:
> > 2014/1/6 Clément Bera <[email protected]>
> >>
> >> Hello,
> >>
> >> here I have a class
> >>
> >> A>>==
> >> ^ true
> >>
> >> Now:
> >> a := A new.
> >> b := A new.
> >> a == b "Answers false"
> >> a perform: #== with: b "Answers true"
> >>
> >> Do I have to remove the usage of the byte code for #== in the compiler
> to
> >> be able to override == ?
> >>
> >>
> >
> >
> > No, a==b should be used for "are the same Objects" (pointing to the same
> > object) and not "are equal".
> > Look for example at the commentn for ProtoObject>>==
>
> Given the kinds of things Clément does, I suspect he knows full well
> the difference between #== and #=.
>
> My understanding is that the compiler inlines #== sends like it does
> with #timesRepeat: and ifTrue:ifFalse:. So yes, you'd need to fiddle
> with the compiler for any #== overrides to actually run.
>
> (I'm keen for Marcus to show us how exactly to do that in Opal!)
>
> frank
>
> > Nicolai
>
>
