opEquals and the Non-Virtual Interface idiom

[grauzone]

Andrei Alexandrescu wrote:
> Here's an article about the perils of equals in Java (opEquals in D):
> 
> http://www.ddj.com/article/printableArticle.jhtml;jsessionid=GFKUCQH5S4IHNQE1GHOSKHWATMY32JVN?articleID=184405053&dept_url=/java/ 
> 
> 
> 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. The implementation above ensures symmetry
> of equality and has each class implement a simpler primitive.
> 
> What do you think?

Eh, now after all this discussion, we're going to allow even "this" to 
be null? That seems like a backstep...

Implementing opEquals as a global/static function, that calls the actual 
Object.opEquals virtual method would be so much more straight forward.

PS: I agree about the NVI thing. If you'd go to extend the language for 
"NVI", couldn't we just introduce a second type of virtual function that 
works this way:
1. the super class' implementation is _always_ called first
2. the super class function can decide to "call down" to the sub class' 
implementation of the same method
=> no extra do<something> method needed, and the code is (possibly) clearer.

> Andrei