opEquals and the Non-Virtual Interface idiom

[Andrei Alexandrescu]

Justin Johansson wrote:
> Andrei Alexandrescu Wrote:
> 
>> It turns out this is a great example for NVI. In D, we could and should
>> do the following:
>>
>> class Object {
>>      // Implement this
>>      private bool opEqualsImpl(Object rhs) {
>>          return false;
>>      }
>>      // Use this
>>      final bool opEquals(Object rhs) {
>>          if (this is rhs) return true;
>>          if (this is null || rhs is null) return false;
>>          return opEqualsImpl(rhs) && rhs.opEqualsImpl(this);
>>      }
>> }
> 
> "I took advantage of the fact that in a final function this may be null without an access violation."
> 
> That "advantage" cannot be the general case?
> Surely that statement is only true when the final function is in a base class, X, (and X can only be Object in D, right?)
> for reason that the compiler can spot that the method is never overriden in ANY subclass of X (Object) , and therefore the method can be called directly rather than having to be dispatched through a VFT and consequently there is no VFT entry for that method/function.

Sorry, indeed I meant a "introducing final" function, not a final 
function. A final function that overrides one in the base class must 
often go through the vtable. Though if a final function (introducing or 
not) gets called for the static type that made it final, it needn't go 
through the vtable so a null this could be allowed inside of it.


Andrei