There's an inter-related issue that exhibits this "short circuit" behavior: *any* set of methods with the same basic name (foo, get, put, opShl ...) do the same thing. For example, if I have two classes:

class A
{
    void foo(int x){}
    void foo(char[] x){}
    void foo(real x){}
}

class B : A
{
  void foo (ubyte x){}
}

void test()
{
   B b = new B();

   b.foo ("test");
}

The b.foo("test") generates a similar compile error ("function foo (ubyte x)
does not match argument types (char[4])"). Apparently, once the basic name
is found within a given class, the method resolver stops looking further
down the inheritance chain for a better match. I don't like this, but it's
per design (C++ does the same?).

Walter has a way around this particular issue using alias: there's an additional small section in the online manual discussing it's use. However, it's not fully supported in  release 0.81, and I don't know if it would resolve Ivan's opShl_r problem. I got around the same _r issue (for DSC) by applying an interface instead.

- Kris


"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:c3mdn2$225h$1@digitaldaemon.com...
> I asked this question before but here it is again:
> For example i have this code
>
> class A
> {
>  A opShl(int x)
>  {
>   printf("%d",x);
>   return this;
>  }
>  A opShl(char[] x)
>  {
>   printf("%.*s",x);
>   return this;
>  }
> }
>
> class B
> {
>  A opShl_r(A a)
>  {
>   //some code..
>   return a;
>  }
> }
>
> int main(char[][] args)
> {
>  A a;
>  a << 4 << " " << 12 << "\n";
>  B b = new B();
>
>  a << b;
>  getch();
>  return 1;
> }
>
> The line a<<b; causes this compilation error:
> E:\D language\learn_d\cout\cout.d(36): function opShl (int x) does not
match
> argument types (B )
>
> The compiler look for A.opShl(B) but it doesnt seam to look for
> B.opShl_r(A)??
> If A.opShl(*) functions don't exist then the compiler finds and calls
> B.opShl_e(A),
> but then the first line
>  a << 4 << " " << 12 << "\n";
> doesn't work!
>
> So is this a bug?
> I hope it is and that it gets fixed!
>
>
>

Manfred Nowak schrieb:

> Ilya Minkov wrote:
> 
> [...]
> 
>>Imagine A doesn't define .Op and there is a ton arbitrary code which defines .Op_r(A). Then the author of A decides to add a few .Op overloads to it. This breaks all other code which relies on the definitions of .Op_r(A), even if there is *no* *direct* *conflict*, that is no definition of C.Op_r(A) corresponds to A.Op(C) simply because the author of A is not aware of C, but C is aware of and requieres/uses A.
> 
> 
> I think that this is the pioneering argument, provided that it is
> posssible to code .Op_r by having access only to the public parts of A.
> 
> Now to the next steps:
> 
> 1) should the compiler check for competing overloads that may coincide,
> but actualyy do not; or should this checking only be done, when an
> overload is actually established; or should this being laid into the hands
> of the implementor of the compiler.

We can solve it like many similar questions. It is an error to define ambiguous overloads. It is a quality of implementation issue, if and under what circumstances the compiler can actually detect such an error. I would think that a simple compiler may provide the direct .op overload a precedence, while an advanced compiler may, when compiling a class which contains B.op_r(A), check that there is no match for A.op(B) and indicate an error if there is, and vice versa. I think i have to think over it a bit, since D allows covariant arguments, as opposed to C++ where they are invariant.

> 2) especially in the not overloaded case of `<<' it is defined, that the
> type of the result must be the type of the left operand. Should the
> compiler check the overloading functions for this requirement?

Hard to tell. I think rather not, as it currently is.

> Note: I think the latter has to do with the term `abuse', that sometimes
> drop into the discussions here. This reminds me of the french quotation
> marks "<<" and ">>". Would it be abuse, if someone would overload the
> shift operators in such a way, that they can be used as quotation marks?
> Moreover, in france quotations are made like "<< quoted text >>", whereas
> in germany the quotations are made ">> quoted text <<", if this quotation
> marks are used at all.

Not much i could say here. Numeric operators were foreseen for numeric stuff, other operators were foreseen for their corresponding meanings. And while sprinkled abuse in general code may be very misleading, there is e.g. a C++ library which defines parsers in an elegant manner by using up an operator abuse. The way it is done there, the abuse is obvious and thus doesn't lead to problems.

-eye

Kris schrieb:

> There's an inter-related issue that exhibits this "short circuit" behavior:
> *any* set of methods with the same basic name (foo, get, put, opShl ...) do
> the same thing. For example, if I have two classes:

--- 8< --- >8 ---

> The b.foo("test") generates a similar compile error ("function foo (ubyte x)
> does not match argument types (char[4])"). Apparently, once the basic name
> is found within a given class, the method resolver stops looking further
> down the inheritance chain for a better match. I don't like this, but it's
> per design (C++ does the same?).

Yes, it is by design and C++ does the same IIRC. I think there was some smart reason to it. You have to import all other defs using alias.

> Walter has a way around this particular issue using alias: there's an
> additional small section in the online manual discussing it's use. However,
> it's not fully supported in  release 0.81, and I don't know if it would
> resolve Ivan's opShl_r problem.

No, it won't. Incompatible types. And this issue is no way related. Both behaviours are parts of specification.

> I got around the same _r issue (for DSC) by
> applying an interface instead.

A pity it doesn't help for structs. If we had boxing it would, but then we would loose a lot of performance.

-eye

My mistake ... <g>

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c3vf6p$242t$1@digitaldaemon.com...
> No, it won't. Incompatible types. And this issue is no way related. Both behaviours are parts of specification.

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message
news:c3vf6p$242t$1@digitaldaemon.com
| Kris schrieb:
|
|| There's an inter-related issue that exhibits this "short circuit"
behavior:
|| *any* set of methods with the same basic name (foo, get, put, opShl ...)
do
|| the same thing. For example, if I have two classes:
|
| --- 8< --- >8 ---
|
|| The b.foo("test") generates a similar compile error ("function foo (ubyte
x)
|| does not match argument types (char[4])"). Apparently, once the basic
name
|| is found within a given class, the method resolver stops looking further
|| down the inheritance chain for a better match. I don't like this, but
it's
|| per design (C++ does the same?).
|
| Yes, it is by design and C++ does the same IIRC. I think there was some
| smart reason to it. You have to import all other defs using alias.
|

However, the same can't be done for constructors.

-----------------------
Carlos Santander Bernal

Carlos Santander B. schrieb:

> However, the same can't be done for constructors.

They should call superclass constructors.

-eye

You're right, it should work, and it does now. -Walter

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:c3mdn2$225h$1@digitaldaemon.com...
> I asked this question before but here it is again:
> For example i have this code
>
> class A
> {
>  A opShl(int x)
>  {
>   printf("%d",x);
>   return this;
>  }
>  A opShl(char[] x)
>  {
>   printf("%.*s",x);
>   return this;
>  }
> }
>
> class B
> {
>  A opShl_r(A a)
>  {
>   //some code..
>   return a;
>  }
> }
>
> int main(char[][] args)
> {
>  A a;
>  a << 4 << " " << 12 << "\n";
>  B b = new B();
>
>  a << b;
>  getch();
>  return 1;
> }
>
> The line a<<b; causes this compilation error:
> E:\D language\learn_d\cout\cout.d(36): function opShl (int x) does not
match
> argument types (B )
>
> The compiler look for A.opShl(B) but it doesnt seam to look for
> B.opShl_r(A)??
> If A.opShl(*) functions don't exist then the compiler finds and calls
> B.opShl_e(A),
> but then the first line
>  a << 4 << " " << 12 << "\n";
> doesn't work!
>
> So is this a bug?
> I hope it is and that it gets fixed!
>
>
>