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