Skip to main content

Operator overloading (again) and functions

131 replies [Last post]
m_r_atkinson
Offline
Joined: 2003-08-29
Points: 0

Add operator overloading to Java but make it only usable within the java.* and javax.* package hierarchies. This would allow complex, interval arithmetic, matrix and vectors, etc. to be added. It would allow JCP JSRs to add well thought out operators while not allowing the abuse that making the facility available to everyone would lead to.

Add a "function" keyword modifier to methods that means that the method has no side effects. This has most of the advantages of "const" modifiers to methods and their parameters while being very simple.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
chrisadamson
Offline
Joined: 2003-08-27
Points: 0

> Why don't we make a poll proposal?
>
> Do you think "operator overloading" would be a
> welcome feature in Java language?
>
> a) NO!! I want to read my coworkers code and know
> what it does
> b) YES!! Give us the freedom to use operation
> overload in our classes
> c) YES.. but only on Number subclasses for the
> natural operation (+ - * /)
> d) YES.. but only on java.* javax.* classes and
> their
> addition should be approved by Sun

I'm game, though I might have to shorten the descriptions a little bit.

Any other thoughts on this? New polls go up on Fridays.

--Chris (invalidname)
Editor, java.net

jwenting
Offline
Joined: 2003-12-02
Points: 0

> > Why don't we make a poll proposal?
> >
> > Do you think "operator overloading" would be a
> > welcome feature in Java language?
> >
> > a) NO!! I want to read my coworkers code and know
> > what it does
> > b) YES!! Give us the freedom to use operation
> > overload in our classes
> > c) YES.. but only on Number subclasses for the
> > natural operation (+ - * /)
> > d) YES.. but only on java.* javax.* classes and
> > their
> > addition should be approved by Sun
>
> I'm game, though I might have to shorten the
> descriptions a little bit.
>
> Any other thoughts on this? New polls go up on
> Fridays.
>
What about simply:
Do you think operator overloading is a good idea?
1) No
2) yes

And another one:
Should Sun add everything anyone ever suggested to the core language?
1) hell no
2) sure, why not

insac
Offline
Joined: 2003-06-29
Points: 0

> What about simply:
> Do you think operator overloading is a good idea?
> 1) No
> 2) yes

:-)
That's too easy..

It's a good idea that can be horrendously misused..

Unless somebody finds a way to avoid its misuse, "operator overloading" wouldn't be a welcome addition. That's why I tried adding two of the proposals that has emerged from this forum to try avoiding its misuse by developers.

> And another one:
> Should Sun add everything anyone ever suggested to
> the core language?
> 1) hell no
> 2) sure, why not

1) hell no
(but there's nothing wrong in discussing ideas and try to find pros, cons, opportunities and constraints of new features)

However, don't worry.. it seems the majority of Java developers agree with you that the "operator overloading" is not a welcome feature.

Bye,
Fabio

fuerte
Offline
Joined: 2004-11-22
Points: 0

> However, don't worry.. it seems the majority of Java
> developers agree with you that the "operator
> overloading" is not a welcome feature.

"Don't worry"? That's exactly the reason to be worried! :-)

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

why it is always said that the majority of java developers are not welcomming operator overloading

this is a big tail.

why don't u make some survey or voting and I am sure that supporters of operator overloading will exceed 70%

so stop this big false saying please

mthornton
Offline
Joined: 2003-06-10
Points: 0

> why don't u make some survey or voting and I am sure
> that supporters of operator overloading will exceed
> 70%

http://today.java.net/pub/pq/83

57% opposed operator overloading. Of course polls of this sort should always be taken with a large dose of salt, but you aren't going to get a more reliable result without spending quite a bit of money.

baftos
Offline
Joined: 2005-12-09
Points: 0

Answer such as "it's complicate", "people will abuse it" should be discarded. If and only if the answer is in favor of operator overloading, I would poll people about how.

To me, if the language could enforce or strongly encourage preservation of the operator attributes (commutativity, associativity and so on), I would be very glad to have operator overloading. For instance,
to specify that there is no guarantee that a + ( b + c ) will not become c + ( b + a ) at run-time. If it can be done efficiently, as post 71 proposes, that's even better.

jwenting
Offline
Joined: 2003-12-02
Points: 0

sorry kid, "a + (b + c)" should always yield the same result as "(a + b) + c" so your understanding of how operators work is already so flawed you can't be trusted to use them let alone create them.

Abuse is a major reason why OO leads to such a mess in other languages and is exactly why it is not included in Java.

Lack of basic understanding of how operators work among programmers like you makes it even worse.

mthornton
Offline
Joined: 2003-06-10
Points: 0

> sorry kid, "a + (b + c)" should always yield the same
> result as "(a + b) + c" so your understanding of how
> operators work is already so flawed you can't be
> trusted to use them let alone create them.

Even now that doesn't always hold for float or double values.

fuerte
Offline
Joined: 2004-11-22
Points: 0

> > sorry kid, "a + (b + c)" should always yield the
> same
> > result as "(a + b) + c" so your understanding of
> how
> > operators work is already so flawed you can't be
> > trusted to use them let alone create them.
>
> Even now that doesn't always hold for float or double
> values.

Give an example.

mthornton
Offline
Joined: 2003-06-10
Points: 0

double eps = Math.pow(2, -53);
double a = (1+eps)+eps;
double b = 1+(eps+eps);
System.out.println("a="+a);
System.out.println("b="+b);

The result is

a=1.0
b=1.0000000000000002

This is standard floating point 101 stuff.

fuerte
Offline
Joined: 2004-11-22
Points: 0

Yes but the results are equal. You should not ever compare floats with ==. This is elementary, dear Watson.

mthornton
Offline
Joined: 2003-06-10
Points: 0

The results are only approximately equal. The + operation on floating point is only approximately associative. Another example would be
a = 1
b = -1
c = 1.23456789e-15

jwenting
Offline
Joined: 2003-12-02
Points: 0

That's not due to the braces but due to rounding errors introduced in any floating point operation.
Mathematically they are identical within the precision of the computational system employed.

If you're using a computer that would have a precision of 1000 decimal places you'd find the results identical to within a 1000 decimal places. On most current systems that precision is maybe 10 decimal places.

sjasja
Offline
Joined: 2004-08-15
Points: 0

[pre]
public class Test
{
public static void main(String args[])
{
double a = 1e20;
double b = -1e20;
double c = 1;

System.out.println((a + b) + c);
System.out.println(a + (b + c));
}
}

% java Test
1.0
0.0
[/pre]
Any numerical methods book should discuss this stuff. I would recommend a little reading to any programmer unfamiliar with floating point order of execution.

fuerte
Offline
Joined: 2004-11-22
Points: 0

> 1.0
> 0.0

It might seem odd but these results are again practically equal, in this case. If you add anything to infinity (besides -infinity), the result is still infinity. This proves nothing. You are just trying to be clever. This has nothing to do with operator overloading. (a + b) + c ~= a + (b + c) still holds true.

sjasja
Offline
Joined: 2004-08-15
Points: 0

I am trying to address the following statement made earlier:

[i]"a + (b + c)" should always yield the same result as "(a + b) + c"[/i]

and the subsequent statement about "flawed understanding".

> (a + b) + c ~= a + (b + c) still holds true.

Aah, now you are talking! The little "~" you put there makes all the difference. "The same" in the earlier statement vs "approximately the same".

In some applications the error generated by the order of execution does not matter. Then there are applications where it matters a great deal. You might find that some physicist and mathematicians would become rather upset if their code were transformed in such a manner without their consent.

The seminal paper "What Every Computer Scientist Should Know About Floating-Point Arithmetic" (google for it) goes as far as to say: "A language definition that does not require parentheses to be honored is useless for floating-point calculations."

YMMV.

jwenting
Offline
Joined: 2003-12-02
Points: 0

> I am trying to address the following statement made
> earlier:
>
> [i]"a + (b + c)" should always yield the same result
> as "(a + b) + c"[/i]
>
> and the subsequent statement about "flawed
> understanding".
>
> > (a + b) + c ~= a + (b + c) still holds true.
>
> Aah, now you are talking! The little "~" you put
> there makes all the difference. "The same" in the
> earlier statement vs "approximately the same".
>

read the SHOULD :)
In an ideal world they yield the same result. In the non-ideal world of a computer they don't always do.
And there lies the crux. If we can't even rely on an operator for a predefined type working reliably according to mathematical theory and practice why should we muddy the waters even further by allowing completely unrelated behaviour to that mathematical theory as well?

I've seen enough C++ code where operators did things that bear no relation at all to what you'd assume of them.
Adding apples and oranges to yield blackberries is one thing, adding trains and planes to yield automobiles is something else entirely.

mullsoft
Offline
Joined: 2006-01-18
Points: 0

> In an ideal world they yield the same result. In the
> non-ideal world of a computer they don't always do.
> And there lies the crux. If we can't even rely on an
> operator for a predefined type working reliably
> according to mathematical theory and practice why
> should we muddy the waters even further by allowing
> completely unrelated behaviour to that mathematical
> theory as well?
>
> I've seen enough C++ code where operators did things
> that bear no relation at all to what you'd assume of
> them.
> Adding apples and oranges to yield blackberries is
> one thing, adding trains and planes to yield
> automobiles is something else entirely.

This is certainly true, but the fact that some people might do stupid things with a feature of the language does not necessarily mean that the feature should not be provided. In Mathematics, addition and other operators are defined for many other entities apart from "ordinary" numbers, such as complex numbers, vectors and matrices all of which can be modelled in Java but any code that uses them is going to look nothing like the underlying maths. This is very important to people working in this domain so if Java does not provide the feature then it is effectively removing itself from consideration as a suitable language.

Mike

boubouzzzz
Offline
Joined: 2005-06-21
Points: 0

bonjour,
@hlovatt 2005-06-22
too much "enthousiasme" kill "enthousiasme"
I think that implementation doesn't depends on java language.
@mthorton 2005-11-27
IDE shouldn't be a good possibility to increase compilation time gain.
@sjasja @jwenting 2005-11-28
before (market decision) jvm sources opened, how can we know how :
int a=2;
int b=3;
int c=a+b;
work fine for all operators ?
double a=1;
double d=1;
System.out.println(((a/10)*(d/10))*100);
great operation :) with a lot of significations about overloading operators ;)
@tackline 2005-12-04
BigInteger, float and double doesn't live in mathematical context.
(and their Object autoboxer)
In all case, they have their operators :)
BigInteger is the fakest number format storage :)
@cowwoc 2005-12-06
java genric would be efficient at your compil time. that the better way they take.
@insac 2005-12-07
yeeeeaaaah ! c+d
but as yours contributors says (char*int=?) (and what about char+int :) ) :
...
@jwenting 2005-12-09
What an agressive post !!
@mthornton 2006-01-11
what is the requested population, with what lobbying before ?
@mthornton 2006-01-25
here we go :D

finally, operator overloading could be dangerous :
- like this, with bad definition of what is an operator.
not dangerous if :
- sources for already operators coded opened.
- Math/OSI/standards resources are centralized in no-national structure.
- implementation free, sun make is business.
- final class for Primitive, like int, String, Complex, Matrix, ... must be defined.
- farest, Country, "real"Currency, Money, ...
- compilation warning breakfast.
- redefinition of equal (maybe := for affection, = for "primitive"/Objects egality and == for ref egality) ... too hard for a language... :(
... even if language will have 2 syntax with differents compilators, given same exploitable bytecode.

as @... says, OAP shouldn't be include in java, because of runtime error detection. if injection is done before runtime, well...

maybe for 7 :p

tackline
Offline
Joined: 2003-06-19
Points: 0

> Because operator overloading would not affect
> existing code, and it should only be used with
> arithmetics and such, it probably would not be used
> by most programmers most of the time.

IMO, operator overloading should be used by most programmers "most of the time". ints and longs have nasty, silent overflow behaviour. Therefore BigInteger, or something slightly more efficient, is probably a better idea for non-low level code. The same goes double for decimal and rational types.

m_r_atkinson
Offline
Joined: 2003-08-29
Points: 0

> My 2 cents... let Sun define a minimalist set of
> operators for well-understood cases like String but
> do not allow developers to define their own.
> Generics, in its current form, deserves the same
> attitude in my view. It is all too attractive to try
> it for your code and the benefits do not outweigh the
> high probability you will run into problems with it
> (due to lack of flexibility).
>
> Start with well-understood cases first. If that works
> well and it makes sense to generalize the approach,
> open up the system to everyone else.
>
> Gili

It seems that this thread will never die! Going back to my original proposal:

> Add operator overloading to Java but make it only usable
> within the java.* and javax.* package hierarchies. This
> would allow complex, interval arithmetic, matrix and
> vectors, etc. to be added. It would allow JCP JSRs to
> add well thought out operators while not allowing the
> abuse that making the facility available to everyone
> would lead to.

This is exactly what I suggested. Confining new operator overloads to the java.* and javax.* package hierarchies means that only well thought out operators that obey traditional mathematical usage will be included.

As it is at present Java is virtually useless for much scientific and engineering computing, as complex, interval, big decimal, matrix, etc. arithmatic is hard to write and read. Earlier this year I translated some reasonably complex highly mathematical algorithms from C++ to Java. The original algorithms were easy to understand using tradition math notation, the C++ algorithm was not too far from that, but the Java was almost impossible to read without having the original algorithm next to it.

My other proposal was for adding a "function" modifier that indicated the method had no side effects. I now think two modifiers would be needed "pure" indicating a pure function with provably no side effects, and "function" indicating a method with no visible side effects (but allowing caching, lazy evaluation and IO - at least output).

Both proposals would be greatly helped by value classes and an immutable modifier to classes to indicated that they cannot be changed after construction. Value classes again might be confined to the java.* and javax.* class hierarchies as they are really only useful to define small objects like complex which should have pass-by-value semantics and be stored in arrays as values (not references). Immutable classes are much more general, knowing that an object cannot change after construction helps reasoning about a program and allows optimisation of many algorithms.

All four proposals (overloading, function, value objects, immutable) are really one package, they fit well together and are probably not worth doing individually.

The biggest problem with this is that all the existing Java libraries do not have any of them. Retrofitting existing libraries would be difficult, perhaps impossible.

I have come to the conclusion the best way forward would be to create a new Java like language with these features, generics done properly, the abolition of primitives, the abolition of casting, traits, closures, etc. This is a major challenge, I have made two attempts to create such a language, but in neither case did I consider the resultant language to be good enough for public viewing.

The Fortress language http://research.sun.com/projects/plrg/ comes close to what I'm looking for. It is I think a bit complex for the average programmer and the syntax is quite different than Java, but perhaps a Java like wrapper in the existing syntax (as a syntax expander) may work.

hlovatt
Offline
Joined: 2003-11-18
Points: 0

I have written an extended compiler:

http://pec.dev.java.net/nonav/compile/index.html

Using this compiler you can have immutable classes by implementing interface Immutable. The methods inside these classes are pure because these classes may only contain immutable fields.

If you do try the compiler out let me know how you go.

tackline
Offline
Joined: 2003-06-19
Points: 0

> > > Okay, you're scaring me. The instant that you
> add
> > > general operator overloading, all of the
> > > non-ambiguous, existing code will suddenly be
> open
> > > for interpretation. That's exactly the problem.
> >
> > I don't think it is being proposed that operator
> > overloads can appear as free functions. Or that
> > operators such as == or = be overloadable.
>
> (A) That's not how I read the many comments for op-ov
> in this thread.
>
> (B) If you didn't, where are you going to draw the
> line? It's a very slippery slope because everybody
> and their cousin has that one area where they just
> "know" that it's worth all of the hassle, cost, risk,
> etc. That's the C++ disease.

The C++ language disease was making std::string work. Java does not have the problems of memory management, different ways to reference memory, backward compatibility with C, etc.

> If you allow op-ov in Java than anybody looking at "a
> + b" has to go hunting around for exactly what a and
> b are to try and figure out what that means. Right
> now the usages of + for primitives and strings are
> distinct enough looking that that's only mildly
> annoying. Allow it for anything and it will always
> been confusing.

A big advantage Java has over C++ is that the common library is established and well used. Put together with the lack of "latent typing", the foundations are secure. If java.util.Set does not to define + to copy the left hand side and addAll to the right hand side, it is highly unlikely to start meaning that with anyone else's implementation. Hopefully java[x].* bods realise + for String concatenation was a mistake.

So if you want to know what + does, it's addition (except for String). To find the details you (or your IDE) do potentially have to look up two classes (if you don't know either of them well).

johnm
Offline
Joined: 2003-06-06
Points: 0

> > > I don't think it is being proposed that operator
> > > overloads can appear as free functions. Or that
> > > operators such as == or = be overloadable.
> >
> > (A) That's not how I read the many comments for op-ov
> > in this thread.
> >
> > (B) If you didn't, where are you going to draw the
> > line? It's a very slippery slope because everybody
> > and their cousin has that one area where they just
> > "know" that it's worth all of the hassle, cost, risk,
> > etc. That's the C++ disease.
>
> The C++ language disease was making std::string work.
> Java does not have the problems of memory management,
> different ways to reference memory, backward
> compatibility with C, etc.

What does all of that have to do with the topic of this thread? The "C++ disease" is that slippery slope style of *thinking*, not any one feature.

> > If you allow op-ov in Java than anybody looking at "a
> > + b" has to go hunting around for exactly what a and
> > b are to try and figure out what that means. Right
> > now the usages of + for primitives and strings are
> > distinct enough looking that that's only mildly
> > annoying. Allow it for anything and it will always
> > been confusing.
>
> A big advantage Java has over C++ is that the common
> library is established and well used. Put together
> with the lack of "latent typing", the foundations are
> secure. If java.util.Set does not to define + to copy
> the left hand side and addAll to the right hand side,
> it is highly unlikely to start meaning that with
> anyone else's implementation. Hopefully java[x].*
> bods realise + for String concatenation was a
> mistake.
>
> So if you want to know what + does, it's addition
> (except for String). To find the details you (or your
> IDE) do potentially have to look up two classes (if
> you don't know either of them well).

Huh? The topic is what happens if we add op-ov to Java. The proponents of op-ov think that op-ov won't have any negative effects on existing code and coders and the fact is that it will.

tackline
Offline
Joined: 2003-06-19
Points: 0

> What does all of that have to do with the topic of
> this thread? The "C++ disease" is that slippery
> slope style of *thinking*, not any one feature.

The pathogen of C++ thinking is C++. Assuming Java programmers are programming in Java, C++ think is not a problem. If programmers tried to apply operators inappropriately, then it would stick out like a sore thumb.

I admit when I was learning C++ I used >> and << to read and write bytes to and from a pixie. However, I was following the library design, I didn't actually use the "STL" part of the standard library at all and it was just a beginners mistake. If Java gained operator overloading then to repeat the mistake newbies would have to somehow entirely ignore the library and never learn. Far worse crimes happen in Java.

> Huh? The topic is what happens if we add op-ov to
> Java. The proponents of op-ov think that op-ov won't
> have any negative effects on existing code and coders
> and the fact is that it will.

Do you mean it will have effect on the semantics of any existing code (certainly not true for any sensible implementation). Or do you mean, programmers will have to think whether + is being applied to int or BigInteger, even in old code (that's a problem??).

cowwoc
Offline
Joined: 2003-08-24
Points: 0

My 2 cents... let Sun define a minimalist set of operators for well-understood cases like String but do not allow developers to define their own. Generics, in its current form, deserves the same attitude in my view. It is all too attractive to try it for your code and the benefits do not outweigh the high probability you will run into problems with it (due to lack of flexibility).

Start with well-understood cases first. If that works well and it makes sense to generalize the approach, open up the system to everyone else.

Gili

fuerte
Offline
Joined: 2004-11-22
Points: 0

> My 2 cents... let Sun define a minimalist set of
> operators for well-understood cases like String but
> do not allow developers to define their own.
> Generics, in its current form, deserves the same
> attitude in my view. It is all too attractive to try
> it for your code and the benefits do not outweigh the
> high probability you will run into problems with it
> (due to lack of flexibility).

What. Generics must be used by every programmer if he ever uses Hashtable, for example. You can't use it without generics, or at least you should not to.

> Start with well-understood cases first. If that works
> well and it makes sense to generalize the approach,
> open up the system to everyone else.

Because operator overloading would not affect existing code, and it should only be used with arithmetics and such, it probably would not be used by most programmers most of the time.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

My point was that Collections should make use of Generics and developers could make use of Collections, but developers would not be able to create their own classes which make use of Generics.

Same thing would go with operator overloading. Sun would define the use of Generics and operator overloading over a small and well-understood subset of Java and developers would not be able to add their own.

Gili

fuerte
Offline
Joined: 2004-11-22
Points: 0

> My point was that Collections should make use of
> Generics and developers could make use of
> Collections, but developers would not be able to
> create their own classes which make use of Generics.

Okay, sorry that I didn't get it at first. That makes a lot of sense (in most cases).

> Same thing would go with operator overloading. Sun
> would define the use of Generics and operator
> overloading over a small and well-understood subset
> of Java and developers would not be able to add their
> own.

That again makes sense in most of the cases, but not always. Some people would like to add them, so it should not be forbidden. In practise the feature would not be used (in that sense) by most of the programmers.

johnm
Offline
Joined: 2003-06-06
Points: 0

> can anybody here tell us how much is the cost of
> adding operator overloading to java in terms of
> developement cost of the SDK or if it has any
> conflict with existing features of java.

Hmm... Isn't it clear that the cost in terms of the impact to existing code is huge? a + b immediately becomes ambiguous and people would have to go hunting to figure out all of the types, any coercions (which auto-boxing would make even more nasty), etc.

fuerte
Offline
Joined: 2004-11-22
Points: 0

> Hmm... Isn't it clear that the cost in terms of the
> impact to existing code is huge?

It is none, because the existing code does not use operator overloading.

> a + b immediately
> becomes ambiguous and people would have to go hunting
> to figure out all of the types, any coercions (which
> auto-boxing would make even more nasty), etc.

a + b is already ambiguous, you have to know the type of a and b before you know what happens.

johnm
Offline
Joined: 2003-06-06
Points: 0

> > Hmm... Isn't it clear that the cost in terms of the
> > impact to existing code is huge?
>
> It is none, because the existing code does not use
> operator overloading.

Okay, you're scaring me. The instant that you add general operator overloading, all of the non-ambiguous, existing code will suddenly be open for interpretation. That's exactly the problem.

tackline
Offline
Joined: 2003-06-19
Points: 0

> Okay, you're scaring me. The instant that you add
> general operator overloading, all of the
> non-ambiguous, existing code will suddenly be open
> for interpretation. That's exactly the problem.

I don't think it is being proposed that operator overloads can appear as free functions. Or that operators such as == or = be overloadable.

Given two references to BigInteger, a and b. There is no current meaning to the expression a + b. With an operator overload declared in the BigInteger class, it could be given a meaning. A meaning only definable by the BigInteger class. Subclasses needn't be allowed to override the overloading in general (although the operator override could forward to a virtual instance method).

It becomes more difficult where the types are different. But there are ways around it.

johnm
Offline
Joined: 2003-06-06
Points: 0

> > Okay, you're scaring me. The instant that you add
> > general operator overloading, all of the
> > non-ambiguous, existing code will suddenly be open
> > for interpretation. That's exactly the problem.
>
> I don't think it is being proposed that operator
> overloads can appear as free functions. Or that
> operators such as == or = be overloadable.

(A) That's not how I read the many comments for op-ov in this thread.

(B) If you didn't, where are you going to draw the line? It's a very slippery slope because everybody and their cousin has that one area where they just "know" that it's worth all of the hassle, cost, risk, etc. That's the C++ disease.

> Given two references to BigInteger, a and b. There is
> no current meaning to the expression a + b. With an
> operator overload declared in the BigInteger class,
> it could be given a meaning. A meaning only definable
> by the BigInteger class. Subclasses needn't be
> allowed to override the overloading in general
> (although the operator override could forward to a
> virtual instance method).

If you allow op-ov in Java than anybody looking at "a + b" has to go hunting around for exactly what a and b are to try and figure out what that means. Right now the usages of + for primitives and strings are distinct enough looking that that's only mildly annoying. Allow it for anything and it will always been confusing.

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

>If you allow op-ov in Java than anybody looking at "a + b" has to go hunting around for exactly what a and b are to try and figure out what that means.

this is silly argument

because if I read
a.add(b)
I should go to hunt around to find what this means

jwenting
Offline
Joined: 2003-12-02
Points: 0

> I have a solution for your problem, believe or not.
> Make the operator overloading in Java so that it is
> always trivial (for the editor or compiler) to
> replace operators with function calls or vice versa.
> This way you could always have
>

The solution is to collect everyone who wants to add operator overloading and dump them in the Pacific ocean a thousand miles from the nearest land.

sjasja
Offline
Joined: 2004-08-15
Points: 0

>> Some of us simply have too much experience with
>> operator overloading and its rampant misuse.
>
> Well then you should not be allowed to use it, hehe.
> But please give it to the rest of us, who know how to
> use it.

Ok, I'll try to explain this once more.

Programmers don't live in a vacuum. They use other programmers' libraries and APIs. They need to maintain other peoples' code. A professional programmer needs to know his tools, including programming languages. The features and the interactions of features. A real programmer can't decide to ignore language features.

"You shouldn't be allowed to use it" -- the problem isn't me overloading "<<" to mean "output" (I wouldn't do that of course), it is that I need to use and maintain code written by others that is laden with such cute tricks.

In real world programming, "if you don't want to use feature X then ignore it" is not a valid argument for turning a language into a junkyard of features.

fuerte
Offline
Joined: 2004-11-22
Points: 0

> "You shouldn't be allowed to use it" -- the problem
> isn't me overloading "<<" to mean "output" (I
> wouldn't do that of course), it is that I need to use
> and maintain code written by others that is laden
> with such cute tricks.

I have a solution for your problem, believe or not. Make the operator overloading in Java so that it is always trivial (for the editor or compiler) to replace operators with function calls or vice versa. This way you could always have

new StringBuilder(new String({'a', 'b'})).Append(new String({'c', 'd'}).ToString()

instead of

"ab" + "cd"

even if the original writer used operator overloading.

sjasja
Offline
Joined: 2004-08-15
Points: 0

> I have a solution for your problem, believe or not.

That doesn't seem like a solution to overload abuse, it seems more like a new problem. I am at a loss as to how to make you understand the problem so you wouldn't try to find "solutions" to non-problems.

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

can anybody here tell us how much is the cost of adding operator overloading to java in terms of developement cost of the SDK or if it has any conflict with existing features of java.

I think this cost is the real cause for sun engineers to be that much of hatred to operator overloading.

mthornton
Offline
Joined: 2003-06-10
Points: 0

I don't think Sun engineers hate overloading any more (or less) than the Java community as a whole. The opposition to overloading is widespread amongst 'refugees' from C++.

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

>> doesn´t matter..
>> What we will gain with operator overloading ?
>> what is the difference between to write:
>> A + B;
>> A.plus(B);
>> just a few letters )

That is really so silly comment.
I could not think that a programmer would write operator overloading just to make A + B

many applications are equation oriented. I mean that it so important for the programmer to see the exuation as it is written on the paper to be able to figure the correctness of his application.

all statements that say overloading make code ambijious are false.

because If I am going to overload a + or * operator that mean I am going to use it extensively and my application will have alot of equations.

and for my code reader, it would be important to see the equations to be able to know what are the equations. He will have to read the definition of + or * just once but then the equation of my application will be very nice to understand

I think those are againist operator overloading are oblivious of the context of their porgrams.

I just would overload operator only if really my application use equations extensively and for written A+B

All I see in this forum that all programmers are really inerested in having operator overloading but just sun programmers are againist.

why sun engineers negelects the needs of java progammers that much

sjasja
Offline
Joined: 2004-08-15
Points: 0

> I mean that it so important for the programmer to see the exuation as
> it is written on the paper to be able to figure the correctness of his
> application.

What kind of mathematical software do you write where +-*/ makes your code look like mathematical texts? What field are you in?

Don't you need division ("/" is a poor substitute for a real horizontal line), multiplication (have to write "a*b" instead of mathematics "ab"), roots, dot product, matrixes, vectors, sets, factorial, union and other set operations, sum over, cartesian product, derivation, integration, partial integration, exponentiation, absolute value, postfix operators, subscripts, parenthesis other than (), percent, equivalence, negation, quantifiers (all/exists), disjunction/conjunction, membership, sub-/superset, ...?

Overloading +-*/ allows for kindergarten math at best. Although if I recall the first mathematical operators I was taught in school were union and intersection, so perhaps not even that.

> I think those are againist operator overloading are oblivious of the
> context of their porgrams.

Some of us simply have too much experience with operator overloading and its rampant misuse.

> All I see in this forum that all programmers are really inerested in
> having operator overloading but just sun programmers are againist.

Your assumption is incorrect. I suspect there are very few or no Sun employees in this thread. This is just too outlandish...

fuerte
Offline
Joined: 2004-11-22
Points: 0

> Some of us simply have too much experience with
> operator overloading and its rampant misuse.

Well then you should not be allowed to use it, hehe. But please give it to the rest of us, who know how to use it.

ramimahdi
Offline
Joined: 2004-05-29
Points: 0

yah I agree with you fuerte 100%

if for a software development company there is difficulty for their programmers to read operater overloading code, then the teams' leaders should put rules to their programmers not to use it.

But not to ask sun not to make it available for the others who get great benefits from operator overloading

mthornton
Offline
Joined: 2003-06-10
Points: 0

One alternative to adding operator overloading to the language would be to use annotations on methods which we wished to see as operators together with a smart IDE/viewer that would display the code in operator form instead of the method calls that actually appeared in the file. Even better we would not need to restrict ourselves to the operators already in use, but could use any operator like symbol available in unicode. WHen typing code, the IDE could offer a list of relevant operations so we could mostly avoid the awkwardness of typing the more unusual operators.

Those who prefer operators can use an enhanced viewer, while those who prefer method form will look at the real file. Furthermore we have the assurance of several posters here that the method form will not be incomprehensible!

johnm
Offline
Joined: 2003-06-06
Points: 0

> If one were to discount C++ as an aberation are there
> any other examples of serious abuse? Mathematicians,
> after all, have been overloading operators to
> reasonable effect for quite a while.

(A) Other than as some theoretical exercise, we cannot discount the lessons of C++ because Java and the Java community are all too similar to the C++ world in nearly all facets/dimensions. It feels like deja vu all over again.

(B) Other folks have already mentioned some other general purpose programming languages which were more coherently designed, from the ground up, to support operator overloading. First off, note how none of those languages have become popular (for good and bad reasons, timing, etc.). Second, note how those languages have pretty rabid followings amongst programmers working on certain kinds of problems (where the strengths of those languages can manifest themselves). Thirdly, look at all of the abuses done with other, similar features such as the C preprocessor and Lisp macros, "annotations" in Java 5, and AOP.

(C) As I noted, math is one place where op-overloading really does seem to provide enough bang for the buck. A large part of that is because math has a lot of reasonably well defined, disciplined constraints. Alas, adding generalized support for op-ov means there's basically no constraints on the hells that programmers can create. Personally, I would much rather see a fully supported, high-end math system added to Java with operator overloading.

sjasja
Offline
Joined: 2004-08-15
Points: 0

> Mathematicians, after all, have been overloading
> operators to reasonable effect for quite a while.

It is a rare mathematician who discovers a new mathematical entity and creates a new notation for it. When he does it may well be the high point of his career, so he is likely to be careful about it. And peer review will work to weed out any obviously dumb ideas.

A junior programmer can whip up a couple of classes and a dozen methods before lunch.

Maybe us programmers are just more frequently presented with the opportunity to be cute. And, alas, too often the temptation overpowers us.

rcasha
Offline
Joined: 2003-12-09
Points: 0

Many who disagree with operator overloading keep quoting the example of C++. It's true that oo in C++ was messed up, and I think it's mainly because of the way the C++ libraries like the stream io libraries were implemented: C++ itself set the stage for this wholesale abuse of oo by using the left-shift and right-shift operators for I/O. It followed naturally that there would be other cases of oo abuse from others.

That does not have to be the case with Java. Like I said, operator overloading can be abused just like any other language feature. However if Java starts the ball rolling by implementing oo functionality and adding it to all Number classes and other objects which lend themselves to the concept of being added/subtracted etc., history need not repeat itself.