Manfred Nowak schrieb:

> Ilya Minkov wrote:
> 
> [...]
> 
>>The purpose of _r overloads was to be able to add new overloads in newly written classes to the already exisiting infrastructure.
> 
> [...]
> 
> Do you have a reference for this? I ask, because I do not believe, that
> classes in any infrastructure are not allowed to have other types than
> classes/structs on the left side of a non commutative operator.

Ok, you're right. But here's a real-life example:

A widespread library defines numerical class A. For it, operators to divide it by an integer a float, and so on. are defined. Then you go ahead and write a Fixpoint struct. You want that you can divide A by your fixpoint just as by integer or a float. And you don't want to change A because you don't own it, and because you don't want A to be dependant on your fixpoint. So you define Fixpoint.opDiv_r(A). But hey, in current spec it DOES NOT WORK because A.opDiv(int) or some other unrelated stuff is defined!!!

Now, one could consider not to define opDiv in A at all. But in the examples like above it simply doesn't come into consideration, because there is no other way to make it work with D's built in types!!! This is hardly acceptable. And while there is a workaround for classes by using interfaces, for structs it is a real dead end.

> [...]
> 
>>but it doesn't match) a reversed overload has to be searched in B.
> 
> I do not believe that it is possible to code such overloads in the general
> case you established as an example. How can you assure, that it would
> suffice to have access to the public parts of class/struct A?

I cannot, but imagine you are writing a library. You want that people can write extensions to your library. So you make sure they can - by making something public, or by providing a constructor. Of course it is only for cases which are foreseen.

In principle, this situation is analogous to that of freestanding operators in C++, just that we don't have "friend", which wouldn't help here either.

>>you could just as well remove all _r overloads!
> 
> A stated above `B.opfunc_r(int)' may still make sense.

Ok. i exaggerated. But the usefulness diminishes to almost zero.

There was a discussion on freestanding operators. Everyone wanted them. Just that they don't live well with D's module system. Walter was strongly against. I had suggested that what they requiere, namely extensibility, can be achieved also with reverse overloads. Now i see that this doesn't work in the current spec. So, the discussion must be unrolled again, either freestanding operators, or reverse overloads which don't fail when non-conflicting direct overloads are defined.

-eye

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c3t1i5$19pm$1@digitaldaemon.com...
> Manfred Nowak schrieb:
>
> > Ilya Minkov wrote:
> >
> > [...]
> >
> >>The purpose of _r overloads was to be able to add new overloads in newly written classes to the already exisiting infrastructure.
> >
> > [...]
> >
> > Do you have a reference for this? I ask, because I do not believe, that classes in any infrastructure are not allowed to have other types than classes/structs on the left side of a non commutative operator.
>
> Ok, you're right. But here's a real-life example:
>
> A widespread library defines numerical class A. For it, operators to divide it by an integer a float, and so on. are defined. Then you go ahead and write a Fixpoint struct. You want that you can divide A by your fixpoint just as by integer or a float. And you don't want to change A because you don't own it, and because you don't want A to be dependant on your fixpoint. So you define Fixpoint.opDiv_r(A). But hey, in current spec it DOES NOT WORK because A.opDiv(int) or some other unrelated stuff is defined!!!
>
> Now, one could consider not to define opDiv in A at all. But in the examples like above it simply doesn't come into consideration, because there is no other way to make it work with D's built in types!!! This is hardly acceptable. And while there is a workaround for classes by using interfaces, for structs it is a real dead end.
>
> > [...]
> >
> >>but it doesn't match) a reversed overload has to be searched in B.
> >
> > I do not believe that it is possible to code such overloads in the
general
> > case you established as an example. How can you assure, that it would suffice to have access to the public parts of class/struct A?
>
> I cannot, but imagine you are writing a library. You want that people can write extensions to your library. So you make sure they can - by making something public, or by providing a constructor. Of course it is only for cases which are foreseen.
>
> In principle, this situation is analogous to that of freestanding operators in C++, just that we don't have "friend", which wouldn't help here either.
>
> >>you could just as well remove all _r overloads!
> >
> > A stated above `B.opfunc_r(int)' may still make sense.
>
> Ok. i exaggerated. But the usefulness diminishes to almost zero.
>
> There was a discussion on freestanding operators. Everyone wanted them. Just that they don't live well with D's module system. Walter was strongly against. I had suggested that what they requiere, namely extensibility, can be achieved also with reverse overloads. Now i see that this doesn't work in the current spec. So, the discussion must be unrolled again, either freestanding operators, or reverse overloads which don't fail when non-conflicting direct overloads are defined.
>
> -eye

All I can say is: Agree complety!

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c3t0ha$17ta$1@digitaldaemon.com...

> In this case the operation is comunitative, so m2 * v1 and v1 * m2 are the same thing.  Check out dig for a good matrix class.
>

Ok but what if i for some reason neaded two vecto classes vectorRow and
vectorColumn
(and nobody can say that noone will ever need something like this)

wtih these two vector classes m2*v1and v1*m2 isn't comutative. It isn't the
same result
if yout multiply a matrix with a vector row from left or from the right
side.

"Juan C" <Juan_member@pathlink.com> wrote in message news:c3t04c$17d8$1@digitaldaemon.com...
> <snip>
> >I was wondering... what is the definition of abuse of operator?
> </snip>
>
> It can't be defined, because not everyone would agree with any particular definition, or even whether or not such a concept is valid.
>
> I could say, "any implementation of an operator that differs substantially
from
> its normal mathematical meaning". But that can be viewed as vague and
maybe only
> half the people in this group would agree that that's abuse anyway. Many,
like
> you perhaps, would argue that any operator can be used for any purpose.
>
> <analogy>
> Even though my SUV _allows_ me to drive anywhere, I am still obliged to
follow
> the roads, so that other drivers can _reasonably predict_ what I'm likely
to do.
> </analogy>
>

Your car allows you to drive anywhere but the comunity doesn't, you can be
punished.
Same with the operators.If i write a library and the users think i am
abusing operators
nobody will use the library, and this will be my punishment!

But we live in a free world so it shouldn't be made impossible to write
inovative code
wich in some context maybe makes sence.

Ivan Senji wrote:

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:c3t0ha$17ta$1@digitaldaemon.com...
>
>  
>
>>In this case the operation is comunitative, so m2 * v1 and v1 * m2 are
>>the same thing.  Check out dig for a good matrix class.
>>
>>    
>>
>
>Ok but what if i for some reason neaded two vecto classes vectorRow and
>vectorColumn
>(and nobody can say that noone will ever need something like this)
>
>wtih these two vector classes m2*v1and v1*m2 isn't comutative. It isn't the
>same result
>if yout multiply a matrix with a vector row from left or from the right
>side.
>
>  
>
Your right I was thinking scalar. Anyway  you shouldn't be able m2 x v1 but if it's possible then it is not much trouble.

-- 
-Anderson: http://badmama.com.au/~anderson/

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c3ueha$e35$1@digitaldaemon.com...
> >
> Your right I was thinking scalar. Anyway  you shouldn't be able m2 x v1 but if it's possible then it is not much trouble.
>

It is mathematicaly possible to do m2 * v1, but it isn't D-possible when the left side class (int this case matrix) has a * operator defined.

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c3ueha$e35$1@digitaldaemon.com...
> Your right I was thinking scalar. Anyway  you shouldn't be able m2 x v1 but if it's possible then it is not much trouble.

It is amthematicaly possible to do that, but it isn't D-possible when the
left side
class (in this case matrix) has any opMul defined! This is the problem: If
class matrix
doesn't have any operators opMul then vector is searched for
opMul_r(matrix),
but in the case of existance of matrix.opMul it doen't work.

Ivan Senji wrote:

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:c3ueha$e35$1@digitaldaemon.com...
>  
>
>>Your right I was thinking scalar. Anyway  you shouldn't be able m2 x v1
>>but if it's possible then it is not much trouble.
>>    
>>
>
>It is amthematicaly possible to do that, but it isn't D-possible when the
>left side
>class (in this case matrix) has any opMul defined! This is the problem: If
>class matrix
>doesn't have any operators opMul then vector is searched for
>opMul_r(matrix),
>but in the case of existance of matrix.opMul it doen't work.
>
>  
>
I guess it's mythically ok if you use the vector (1x3 matrix) as a row for  m x v  and a column for v x m.

-- 
-Anderson: http://badmama.com.au/~anderson/

Conclusion?: The way that operators work now should be changed because it is
dangerous.
The D way is generaly a good solution but they still have a big problem with
*_r operators!

"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!
>
>
>

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.

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?

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.

So long!