Unified function call syntax

Sergey Gromov snake.scaly at gmail.com
Mon Sep 8 00:11:30 PDT 2008


Manfred_Nowak <svv1999 at hotmail.com> wrote:
> Sergey Gromov wrote:
> 
> > you essentially define (semantically)
> > 
> >      class char[] {
> >           bool equals(char[] b) {...}
> >      }
> 
> But then one semantically inherets that class---and therefore should be 
> able to override/overload the inhereted methods, but you deny this. 
> Why?

You cannot derive from an array.  When you define

    class A {
        bool equals(Object o) {...}
    }

you define a method, A.equals(), which cannot be called for an object of 
char[] class.

Of course not everything is that nice. Consider

    bool equals(char[] a, char[] b) {...}
    class A {
        bool equals(char[] a, char[] b) {...}
        bool foo() {
            char[] x, y;
            bool r1 = equals(x, y);  // I expect A.equals() to be called
            bool r2 = x.equals(y);   // I expect .equals() to be called
        }
    }

Here syntax dictates different expectations for something which 
semantically must be the same.  So I personally put this 'unified 
function call' feature in the same basket with property call syntax: a 
'sugar' which brings more ambiguity to the language than it actually 
helps rapid development.



More information about the Digitalmars-d mailing list