Unified function call syntax

Sergey Gromov snake.scaly at gmail.com
Mon Sep 8 03:58:57 PDT 2008


Denis Koroskin <2korden at gmail.com> wrote:
> On Mon, 08 Sep 2008 11:11:30 +0400, Sergey Gromov <snake.scaly at gmail.com>  
> wrote:
> 
> > 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.
> 
> There is not that much of an ambiguity. First of all, member functions can  
> not be used as Unified Function Call, only free ones. That's why your  
> example is perfectly valid, I think that everyone expect the same  
> behaviour. It's just a compiler who is doing things wrong (and bugs are  
> already reported).

What is a 'free' function?  How do you define a search rule?  Consider:

    bool equals(char[] a, char[] b) {...}
    class A {
        bool equals(char[] a, char[] b) {...}
        bool foo() {
            bool equals(char[] a, char[] b) {...}
            char[] x, y;
            bool r1 = equals(x, y);  // calls local equals()
            bool r2 = x.equals(y);   // should call local equals(), too
        }
    }

Here x.equals(y) cannot be rewritten as .equals(x, y) because it will 
call global equals() instead of the local one.  This means that for 
x.equals(y) only local and global functions must be considered but any 
methods should be ignored, despite the fact that they are perfectly 
accessible from the call scope.  This requires inventing new scoping 
rules => not quite a 'syntax sugar' anymore.



More information about the Digitalmars-d mailing list