Walter wrote:
> 
> Now this idea has a lot of merit! Thanks for posting it. I *like* it being clearly distinguishable from the native operators.

I don't see that resolving an overloaded operator is any easier just because you have colons around it to distinguish it... the parser generates a tree using expression rules for +, * etc., so no extra complexity there. The code generator then has to decide whether to emit an integer addition for int + int, a floating point addition for float + float, or look up a function in the symbol table for user-defined cases. You still have to choose int+int vs. float+float, so the extra complexity is surely minimal.

It's another story if, as in Algol 68, you can define your own operator
tokens and change operator priorities, or as in Ada where you can
overload
based on the result type rather than the parameter types, but I hope
no-one's suggesting that... :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

John Fletcher wrote:
> 
> kaffiene wrote:
> 
> >
> > Personally I think that overloading is not worth the hype and tends to obfuscate code.  If you *must* implement it, don't do it unless you can use any operators you like (regardless of whether the language supports them natively) and  you must be able to specify your own precedence (that'd be a fun compiler to write!).
> >
> > Peter.
> 
> I know of a C++ compiler (SALFORD C++ http://www.suns.salford.ac.uk/compilers/salfordc/index.shtml) which has a pragma to allow the definition of new operators and specify the position in the precedence.  It also produces very lint like error messages. I could not find a user group.

Algol 68 did this too, many years ago.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

kaffiene wrote:
> 
> (4) It introduces another style for doing very common stuff.  One group of
> programmers does vec.plus(v2) and another does vec + v2.

Without overloading, one group does vec.plus(v2), another does
vec.add(v2).
It's like in the Java API, you have add() for Vectors and put() for
Hashtables -- consistent naming is hard to enforce and something
always goes wrong. If there is an "obvious" name like +, surely
it's better to use that (even at the risk of idiots defing it in
"non-obvious" ways...)?

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

"John English" <je@brighton.ac.uk> wrote in message news:3CD27936.7152F760@brighton.ac.uk...
> kaffiene wrote:
> >
> > (4) It introduces another style for doing very common stuff.  One group
of
> > programmers does vec.plus(v2) and another does vec + v2.
>
> Without overloading, one group does vec.plus(v2), another does
> vec.add(v2).
> It's like in the Java API, you have add() for Vectors and put() for
> Hashtables -- consistent naming is hard to enforce and something
> always goes wrong. If there is an "obvious" name like +, surely
> it's better to use that (even at the risk of idiots defing it in
> "non-obvious" ways...)?
>

This discussion is periodically returning here.
I am in favour of operator overloading for exactly
this reason. Common stuff, such as adding things
already have very common and standardized 'names'
in math, +, -, * and /.

With named functions, you can get:

vec1.Add (vec2);    // seems logical right?
vec1.add (vec2);    // Argh, we are case sensitive...
vec1.Plus (vec2);   // Mmm makes sense too right?
vec1.And (vec2)     // And this too...
vec1.Und (vec2);    // written by a german :)
vec1.En (vec2);     // Or by a dutchmen...

Need I go on?
+ is + and math is math. If you are a programmer
you must know math, period.
Ofcourse + could be interpreted to mean something
different by different people, but this also goes
for named functions. What does matrix1.Mul (matrix2)
mean? Does it do a cross product?
It seems to me operator overloading solves some
problems and introduces some others, but one of the
things it does solve is allow the use of a common
language for describing mathematical operations,
not english, german or dutch, but math itself!

If you are interested, read the thread "Operator
overloading, a way to make everybody happy', it
talks about many of these things, Don't be afraid
of a little flaming here and there though.

In abovementioned thread I proposed a way where
standard interfaces would be defined for supporting
common math operations, such as IAddable, IAssignable,
IComparable etcetera. The compiler would then map the
operators =, ==, <, >, +, -, / and * to these
interfaces, creating some sweet syntax sugar.

Walter has implemented a tweaked version of this for
the comparison operators, where the base class Object
contains functions cmp() and equals() for comparison
and for testing for equality.
The compiler then maps the operators <, <=, > and >=
to cmp() and == and != to equals(). You can overload
the functions cmp() and equals() and you will then
automagically overload the comparison operators too!

At the moment there is no operator overloadin support
for assignment. A big problem with this is how to
distinguish between assignment by reference and by
value. I proposed using = for assignment by reference
and := for assignment by value, but this has not
meet with enthousiastic reception (and for obvious
reasons...). At the moment you will need to call dup(),
but at least it is standard for all objects.

For addition, subtraction, multiplication and division
all bets are off, but this might change quick, like
it has done with the overloading of the comparison
operators and with the inclusion of delegates.. :)
Fingers crossed... :)


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

"John English" <je@brighton.ac.uk> wrote in message news:3CD14339.3146AD65@brighton.ac.uk...
> There are lots of other common applications, too; consider a Date
> class. In Java, the lack of operator overloading means that to add
> a number of days to a Date you have to write this:
>    d.setDate( d.getDate() + n );
> and to compare dates:
>    if (d1.before(d2)) ...

I don't know why Java decided to do dates that way, but I don't think it's the right way. In D (as in C, Javascript, etc.) a date is represented by an arithmetic type. Comparisons, math, etc., on dates are all ordinary arithmetic operations on an ordinary arithmetic type. The only time it has meaning as a date is when it is converted to or from a string, or when things like "day of week" is extracted from it.


> In "sensible" languages (C++, Ada etc.), you can overload operators
> so that you can say "if (d1 + n < d2) ...", which IMHO is a hell of
> a lot more readable.

Your are right, but I don't think Date is the best example <g>.

"Walter" <walter@digitalmars.com> wrote in message news:ab5rnl$1o5t$1@digitaldaemon.com...

> I don't know why Java decided to do dates that way, but I don't think it's

I guess it's because you can then make properties like month, day, dayOfWeek etc, all being members of class Date, rather than global functions.

With operator overloading, it would make sence.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ab63ke$20j7$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ab5rnl$1o5t$1@digitaldaemon.com...
>
> > I don't know why Java decided to do dates that way, but I don't think
it's
>
> I guess it's because you can then make properties like month, day,
dayOfWeek
> etc, all being members of class Date, rather than global functions.
>
> With operator overloading, it would make sence.
>

In MFC Microsoft defined a COleDateTime class which
does just that. It contains a member field which
holds a variable of type DATE (which is an OLE type
that maps to a float) and has all kinds of helper
functions and operators defined to ease working
with it.


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

Walter wrote:
> 
> "John English" <je@brighton.ac.uk> wrote in message news:3CD14339.3146AD65@brighton.ac.uk...
> > There are lots of other common applications, too; consider a Date
> > class. In Java, the lack of operator overloading means that to add
> > a number of days to a Date you have to write this:
> >    d.setDate( d.getDate() + n );
> > and to compare dates:
> >    if (d1.before(d2)) ...
> 
> I don't know why Java decided to do dates that way, but I don't think it's the right way. In D (as in C, Javascript, etc.) a date is represented by an arithmetic type. Comparisons, math, etc., on dates are all ordinary arithmetic operations on an ordinary arithmetic type. The only time it has meaning as a date is when it is converted to or from a string, or when things like "day of week" is extracted from it.

So you can multiply and divide dates? Hmm... I wonder what 8 May 2002 divided by 3 is?

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

John English wrote:

> So you can multiply and divide dates? Hmm... I wonder what 8 May 2002 divided by 3 is?

You can't really multiply or divide a date...but you can do so for a time.  So
you either see a Date as "the time since some epoch," or as a special addable
value, where 2 of the 3 elements in any equation must be Date and the other is a
Time:
    Date = Date + Time
    Time = Date - Date

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"John English" <je@brighton.ac.uk> ha scritto nel messaggio news:3CD90494.484154AF@brighton.ac.uk...
>
> So you can multiply and divide dates? Hmm... I wonder what 8 May 2002 divided by 3 is?

It's the wrong question. The good is:
What 8 May 2002 divided by 16 Oct 1992 is?
And sin(8 May 2002) * cos(16 Oct 1992) ?

:-)

Ciao