| Article: |
What I Hate About Your Programming Language | |
| Subject: | Operator overloading in Java | |
| Date: | 2003-05-14 03:16:09 | |
| From: | anonymous2 | |
|
You wrote: The inconsistencies between what the language allows and what the standard library actually does bother me. If operator overloading is so bad, why does the String class do it?
|
||
Showing messages 1 through 5 of 5.
-
Operator overloading in Java
2003-05-17 19:41:31 anonymous2 [View]
-
Operator overloading in Java
2003-05-14 16:24:49 setok [View]
That is one thing that annoys me about Java: the way some committee somewhere decides to leave things awkward or inconcistent just because they believe I am a bad programmer. It's a programming language for corporate entities who don't trust their employees. Good programmers should be given absolute power. If they create a mess it's then give them the blame. Don't make the better ones suffer because of that possibility. -
Operator overloading in Java
2004-10-20 12:15:40 lokesh21 [View]
will java support operator overloading? -
Operator overloading in Java
2004-10-20 12:15:34 lokesh21 [View]
will java support operator overloading?
-
Should have required StringBuffer
2003-05-14 10:07:23 anonymous2 [View]
I've seen string concats via + --way-- overused and completely unnecessary. For consistancy, they should have required StringBuffer. To the developer, it's still operator overloading. The implementation of that overload (preprocessing during compilation would be a better term) is irrespective to the simple fact that the language bars using + between Objects, yet Strings are allowed to break this rule.
Essentially, Java should have set a single standard and stuck with it.
Java's single compile and run certainly beats the pants off the compile / link / run tedium with C/C++.



> overloading is not necessarily
> intrinsically "bad", but has the potential
> to generate unintuitive code.
On the other hand, if you've ever tried to make a nice matrix Class, you realize why operator overloading is so useful. Having the option available means you are able to apply a more natural coding style when it applies. Further, I have seen far too many unintuitive method and variable names to accept this argument.
> The one supported instance of String
> concatenation is a natural and intuitive
> use of overloading.
To continue my point, having to write something like
u = v1.add(v2);
to add two vectors (as used in Physics, i.e. magnitude and direction) is much more awkward than
u = v1 + v2;
in this context, since this style of infix mathematical notation is the most natural for the problem domain of Physics.
> Also, to eliminate it just in principle for
> consistency would deprive Java programmers of
> an extremely useful timesaver.
I agree that I wouldn't be as happy programming Java without the String concatenation operator. However, my argument for consistency would be in support of a general operator overloading mechanism rather than elimination of String concatenation.
$0.02
-- Tahoma