"anderson" <anderson@firestar.com.au> wrote in message news:agtj1g$l6t$1@digitaldaemon.com...
>
<SNIP>
>
> Also you should add app (append ~) to your list.
>


Yes, you are right.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ags8db$2eot$1@digitaldaemon.com...
> The best thing to me still seems to be giving Object
> a few extra methods, such as add(), sub(), mul()
> and div() and map the operators to calls to these
> functions. This is already done for == I believe?

This is a pretty good idea. My only objection is that I never liked the C++ approach of being able to override the global operator+ too, producing the confusing combination of:

struct A
{
    int operator + (X);
};
int operator+ (A, X);

Note the inherent asymmetry of this, especially if A::operator+ turns out to be virtual. The STL has some complicated examples of how to get into trouble with this, especially when you throw templates into the mix.

A better approach would be to simply disallow overloading the global operators, and say "no" to overloading the syntax:

    1 + A;

An alternative is for the compiler to rewrite (1+A) as (A+1) and then look
for an operator+ overload, but that can lead to trouble for (A+B) where both
A and B overload operator+.

On Wed, 24 Jul 2002 18:09:33 -0700 "Walter" <walter@digitalmars.com> wrote:

> A better approach would be to simply disallow overloading the global operators, and say "no" to overloading the syntax:
> 
>     1 + A;

On other hand, it might be even better to disallow _member_ operators,
and require all operators overloading to be global. Then, you don't
have to care about things like virtual operators, overloading etc -
it's all naturally done by pointer conversions.

"Walter" <walter@digitalmars.com> wrote in news:ahnj39$133m$1@digitaldaemon.com:
> A better approach would be to simply disallow overloading the global operators, and say "no" to overloading the syntax:
> 
>     1 + A;
> 
> An alternative is for the compiler to rewrite (1+A) as (A+1) and then
> look for an operator+ overload, but that can lead to trouble for (A+B)
> where both A and B overload operator+.

There are mathmatical systems where A*B != B*A.

I'm sort of inclined to agree with Pavel and
say that all operators must be defined globally.
The only problem would be not being able to acess
private members.

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns92565926D1F8Cpatcodemooncom@63.105.9.61...
> "Walter" <walter@digitalmars.com> wrote in news:ahnj39$133m$1@digitaldaemon.com:
> > A better approach would be to simply disallow overloading the global operators, and say "no" to overloading the syntax:
> >
> >     1 + A;
> >
> > An alternative is for the compiler to rewrite (1+A) as (A+1) and then
> > look for an operator+ overload, but that can lead to trouble for (A+B)
> > where both A and B overload operator+.
>
> There are mathmatical systems where A*B != B*A.
>
> I'm sort of inclined to agree with Pavel and
> say that all operators must be defined globally.
> The only problem would be not being able to acess
> private members.
>

And protected... You'd end up writting your own add/sub/ect... method anyway.

Order is signficatant. Parhaps you could provide 3 versions with special rules?

Both (default) - Only usable if the other class doesn't have a Both property
to do with this class. (ie this class can't Both to itself.)
Left (L) - Only usable if the other class doesn't have a Right property to
do with this class. (ie this class can Left to itself)
Right (R) - Only usable if the other class doesn't have a Left property to
do with this class.

There doesn't seem to be an easy solution to this problem. There are probably problems that can still occur with the above.

"Patrick Down" <pat@codemoon.com> wrote in message
news:Xns92565926D1F8Cpatcodemooncom@63.105.9.61...
<SNIP>
>
> There are mathmatical systems where A*B != B*A.
>

Does this hold for builtin types?
What I mean is that I know that for matrix mul
this is true, so MatA * MatB != MatB * MatA,
but I think that that is not a problem, because
this rule only applies to builtin types such as
int and double? MatA * 2.0 == 2.0 * MatA
isn't it?

Do you have an example where this would be
a problem? e.g. object * int != int * object
or object * double != double * object?

Maybe with complex numbers?
Mmmm....

--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Walter" <walter@digitalmars.com> wrote in message news:ahnj39$133m$1@digitaldaemon.com...

> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ags8db$2eot$1@digitaldaemon.com...
> > The best thing to me still seems to be giving Object
> > a few extra methods, such as add(), sub(), mul()
> > and div() and map the operators to calls to these
> > functions. This is already done for == I believe?
>
> This is a pretty good idea. My only objection is that I never liked the
C++
> approach of being able to override the global operator+ too, producing the confusing combination of:
>
> struct A
> {
>     int operator + (X);
> };
> int operator+ (A, X);
>
> Note the inherent asymmetry of this, especially if A::operator+ turns out
to
> be virtual. The STL has some complicated examples of how to get into
trouble
> with this, especially when you throw templates into the mix.
>
> A better approach would be to simply disallow overloading the global operators, and say "no" to overloading the syntax:
>
>     1 + A;
>
> An alternative is for the compiler to rewrite (1+A) as (A+1) and then look
> for an operator+ overload, but that can lead to trouble for (A+B) where
both
> A and B overload operator+.

   Like anderson said. You can use different versions. I'd use two, the
"normal" version and the reverse version:

class Vector: object {
  Vector add(Vector other); // Enough for both commutations
  Vector mul(double other); // Vector * double
  Vector rmul(double other); // double * Vector
};

class Matrix: object {
  Matrix add(Matrix other); // Enough for both commutations
  Matrix mul(double other); // Matrix * double
  Matrix rmul(double other); // double * Matrix
  Vector rmul(Vector other); // Vector * Matrix
};

   You can always easily do the disambiguation in whichever manner is most
consistent with D rules.

Salutaciones,
                         JCAB

On Fri, 26 Jul 2002 00:10:16 +0800 "anderson" <anderson@firestar.com.au> wrote:

>> I'm sort of inclined to agree with Pavel and
>> say that all operators must be defined globally.
>> The only problem would be not being able to acess
>> private members.
>>
> 
> And protected... You'd end up writting your own add/sub/ect... method anyway.

Operator overloading is typically used from _within_ the module
where classes are defined, so maybe a special rule stating that
overloaded operator can access private/protected class members
in classes it gets as arguments? Yes, it will be a violation of
strict OOP-approach, but at least it'd: 1) work, and 2) be easy
to understand.

Pavel Minayev <evilone@omen.ru> wrote in news:CFN374629860625579@news.digitalmars.com:

> On Fri, 26 Jul 2002 00:10:16 +0800 "anderson" <anderson@firestar.com.au> wrote:
> 
>>> I'm sort of inclined to agree with Pavel and
>>> say that all operators must be defined globally.
>>> The only problem would be not being able to acess
>>> private members.
>>>
>> 
>> And protected... You'd end up writting your own add/sub/ect... method anyway.
> 
> Operator overloading is typically used from _within_ the module
> where classes are defined, so maybe a special rule stating that
> overloaded operator can access private/protected class members
> in classes it gets as arguments? Yes, it will be a violation of
> strict OOP-approach, but at least it'd: 1) work, and 2) be easy
> to understand.
> 

How about static class members?

class Foo
{

  static add(Foo a, Foo b) { }
  static add(Foo a, int b) { }
};

Why not suply diferent methods for handling comutativity and associativity :

class x : y
{
	override void comute(...) { ... }
	override void associate(...) {...}
	void add(...) { ... }
	void mul(...) {...}
	void div(...) {...}
	void dif(...) {...}
}

anderson <anderson@firestar.com.au> wrote:
> 
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns92565926D1F8Cpatcodemooncom@63.105.9.61...
>> "Walter" <walter@digitalmars.com> wrote in news:ahnj39$133m$1@digitaldaemon.com:
>> > A better approach would be to simply disallow overloading the global operators, and say "no" to overloading the syntax:
>> >
>> >     1 + A;
>> >
>> > An alternative is for the compiler to rewrite (1+A) as (A+1) and then
>> > look for an operator+ overload, but that can lead to trouble for (A+B)
>> > where both A and B overload operator+.
>>
>> There are mathmatical systems where A*B != B*A.
>>
>> I'm sort of inclined to agree with Pavel and
>> say that all operators must be defined globally.
>> The only problem would be not being able to acess
>> private members.
>>
> 
> And protected... You'd end up writting your own add/sub/ect... method anyway.
> 
> Order is signficatant. Parhaps you could provide 3 versions with special rules?
> 
> Both (default) - Only usable if the other class doesn't have a Both property
> to do with this class. (ie this class can't Both to itself.)
> Left (L) - Only usable if the other class doesn't have a Right property to
> do with this class. (ie this class can Left to itself)
> Right (R) - Only usable if the other class doesn't have a Left property to
> do with this class.
>