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 <frank.shearar@gmail.com>
On 6 January 2014 11:11, Nicolai Hess <nicolaihess@web.de> wrote:
> 2014/1/6 Cl�ment Bera <bera.clement@gmail.com>
>>
>> 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