What a pity that Java not Include Operators overloading,Wake up

[Arne Vajhøj]

it's very ugly to write code like this: if (s.equal("Hello")) instead
if(s=="Hello")
the most time we do == for string we mean to content not for pointer!

It is not the best argument for operator overload.

Arne

 

[Arne Vajhøj]

boolean isGreeting(String s) {
return s == "Hello" || s == "Bonjour";
}
...
if (isGreeting(null)) ... // what happens here?

If you make `s == "Hello"' equivalent to `s.equals("Hello")',
how do you avoid NullPointerException above? Put a try/catch
around every test?

Depends on the implementation of the operator.

If it does not check for null then NPE - if it does
then things work fine.

Perhaps extensible operator overloading is not in the
language because people would (ab)use it without thinking
through the consequences. As we've just seen.

Have Gosling or similar ever stated that reason ?

Arne

 

[Arne Vajhøj]

mttc wrote:
...
...

I am a consistent advocate of adding operator overloading to Java, but I
must strongly disagree with this statement. Operator overloading is a
highly controversial feature.

Very true.

Using "==" for content comparison in a language in which there is a lot
of existing code that uses it for identity comparison seems to me to be
exactly the sort of misuse, leading to unreadability, that those people
warn about.

And indeed if operator overloading was added to Java, then the == could
not be overridden for any class that existed before the introduction.

Making == not a very general used operator.

I am convinced that operator overloading would primarily be
used in classes with numeric behavior.

Arne

 

[Arne Vajhøj]

please give me example when you compare strings for his pointers?
and way you think that str1==str2 is not perfect clear code for
content compare?
think again, see that most Dev in Scrip lang and VB/C# think like me.
and why not give us to join to java!

It is fine semantics.

But Java chose a different sematics back in the early 90's.

And it can never be changed.

So next language !

Arne

 

[Chronic Philharmonic]

thanks for all.
[...]

we are very lucky that SUN guys give us: str1 + str2 instead of:
str1.cocat()..

Actually, many Java developers use StringBuilder.append or
StringBuffer.append in preference to the comparatively inefficient String.+
operator. And, append returns "this", so appending is quite concise.

And I really do not feel that a few more characters to express exactly what
I mean, vs. an operator which can be subverted to any ambiguous meaning, is
an advantage.

By the way, I also write in C++ and C#, so I am not just a Java bigot. I
think Sun made the right decision here, while ANSI and Microsoft did not.

 

[Andreas Leitgeb]

The "comparatively inefficient" String concatenation operator is implemented
by StringBuilder.

When building up a String throughout a loop, then the explicit
StringBuilder created before, filled inside and read out after
the loop is surely more efficient, since there's only one sb
for the whole loop, instead of one for each iteration.

Other cases are of equal performance, if done "correctly".
(must be, since bytecode is the same then).

 

[Andreas Leitgeb]

The problem is not operator overloading as such - I am in favor of it.
Your proposal would give a new meaning to a combination of type and
operator that is currently valid with a different meaning.

I'm surprised that no one yet suggested a new operator like "==="
or "=!=" for equal()s functionality.

In the context of Strings, I have the feeling that comparing those
with "==" is *in most cases* a programming error, except for one
case: comparing with null. I also think that dealing exclusively
with interned Strings and String-literals is a corner case, but I
may be wrong here, but anyway, it's of course still legal usage.

 

[Andreas Leitgeb]

I'm surprised that no one yet suggested a new operator like "==="
or "=!=" for equal()s functionality.

Damn, on re-reading it it sounds completely wrong:
of course: "===" for .equals()-behaviour and "=!="
for it's negation.

 

[Tom Anderson]

I'm surprised that no one yet suggested a new operator like "==="
or "=!=" for equal()s functionality.

Ahem!

http://groups.google.co.uk/group/comp.lang.java.programmer/msg/8070d31d6e8b392c?hl=en

I think i'd go for !== rather than =!= for the negation, though. The
etymology of != is surely a combination of !, being the prefix operator
for negation, and ==: ! + == = !== -> !=. Applying the same logic to ! +
=== would give us !==. =!= just looks weird to me. It's also a little
slower to type, since you can't just double-tap the equals key, FWIW.

In the context of Strings, I have the feeling that comparing those with
"==" is *in most cases* a programming error, except for one case:
comparing with null. I also think that dealing exclusively with
interned Strings and String-literals is a corner case, but I may be
wrong here, but anyway, it's of course still legal usage.

Yes, i think there are rather few situations where you want to do identity
comparisons on strings.

tom

 

[Tom Anderson]

I disagree with you on almost everything in your post.

Fair enough!

The one exception I make is for algebraic operators and for "index"
operations ([] specifically)

That would give me 80% of what i want from fully general operator
overloading, so i'd be happy with that as a compromise.

The only trouble with [] is that it has reference semantics which aren't
possible in the current JLS, and any "hack-a-round" is likely to cause
inexcusable performance penalties.

I don't understand. Could you expand on that?

tom

 

[Tom Anderson]

How does this work with lists of scalars? E.g. what would something like
List<Integer> list = ...;
int num = ...;
list.add(num*3);
result in? One additional element of num multiplied by three or three
additional elements of num?

One additional element. If num is an int, then num*3 is an int-valued
expression; the fact that List has a * operator doesn't enter into it.

Here's a dialogue with the python interpreter; you need to know that [x]
is the literal syntax for a list containing a single element x:

num = 1
num *3 3
[num]*3

[1, 1, 1]

When i said "strings and lists" what i meant was that strings and lists
behave the same way - strings are a lot like lists of characters in
python. Well, more like tuples of characters, since they're immutable.

tom

 

[Arne Vajhøj]

I'm surprised that no one yet suggested a new operator like "==="
or "=!=" for equal()s functionality.

Fine idea.

Unfortunately is is the wrong way and we can not make it
the right way.

It seems obvious that it should be:

== value equals
=== same object

Arne

 

[Patricia Shanahan]

Fine idea.

Unfortunately is is the wrong way and we can not make it
the right way.

It seems obvious that it should be:

== value equals
=== same object

Arne

I would certainly have been better to do it that way round from the
start. I'm a bit dubious about using the "==" and "===" pair the other
way round from other languages. Maybe we need a new syntax for content
equality?

Patricia

 

[Andreas Leitgeb]

http://groups.google.co.uk/group/comp.lang.java.programmer/msg/8070d31d6e8b392c?hl=en

indeed, I missed it.

And I agree also on that the meanings of existing == and now
discussed === had better been swapped, but that there is no
chance at this point of time to "repair" that.

 

[Arne Vajhøj]

indeed, I missed it.

And I agree also on that the meanings of existing == and now
discussed === had better been swapped, but that there is no
chance at this point of time to "repair" that.

Whenever a language is defined we are stuck with the decisions
for decades to come.

It is rather important to get i right.

I was very surprised when I found out that the Python folks
wanted to change / in 3.x.

The Java people would never accept something as breaking as that.

Arne

 

[Andreas Leitgeb]

Whenever a language is defined we are stuck with the decisions
for decades to come.

I wonder, if Java had been designed back in 16bit times ...
and/or what will happen, once "32bit" becomes a synonym for
prehistoric ...

 

[mttc]

It is not clear because it doesn't work in C, and it doesn't work in
Java.  == has never meant content compare of objects in Java, so
changing it now would confuse many experienced Java programmers, as well
as add no real value to new Java programmers.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>






It is not clear because it doesn't work in C, and it doesn't work in
Java. == has never meant content compare of objects in Java, so
changing it now would confuse many experienced Java programmers, as well
as add no real value to new Java programmers.

Denial you are right, the Java guys make this mistake in the past, but
after we realize that is MISTAKE
(the all must agree that most use with == for string is for Content
compare) we must looking for solution that give us the best!

my suggest is simple (I not mention it above):
Java start to support Operators Override in new nice way. who say the
Operators is only "==,-,*..", we can add ability to declare new
operators, like eq or === or what we convince. so from now we can
write like this: if(str1 equal str2).
notice that with mmodern environment like NETBean the eq is got
another color, so is well reading. I glad to hear another Idea, but
stay with this ugly code, is Stop java to reach more Developer. you
must think that code like "if(str1 eq str2)" is match faster that
existing str1.equal(str2).

so my wishes is to make java common lang!! please join to me.

I want to notice all, that this is not the first mistake that Java
guys try to solve, look at @override, this is very importent, and must
be on the lang itself, we must fix all original sins and we must get
our developers get free from them.

Also if we thinking fresh, we can add directive to java compiler and
start new Java syntax, or Java Extended or what you like, but get Dev
free from narrow brain.. give us the freedom

 

[Arne Vajhøj]

I wonder, if Java had been designed back in 16bit times ...
and/or what will happen, once "32bit" becomes a synonym for
prehistoric ...

Java is fine for 64 bit usage "just a bit larger than 32 bit".

But at some point in time we will suffer for the limits on
things that are int.

And that will cause either a switch to a new language or some
heavy changes to Java.

Arne

 

[Joshua Cranmer]

my suggest is simple (I not mention it above):
Java start to support Operators Override in new nice way. who say the
Operators is only "==,-,*..", we can add ability to declare new
operators, like eq or === or what we convince. so from now we can
write like this: if(str1 equal str2).

If operator overloading is controversial, creation of new operators is
even more so. At least '<<' has a clear basis point for code (it shifts
characters to the left), but what the heck is `a $ b' supposed to mean?

Your proposal also involves using alphanumeric sequences as potential
operators, which is very bad. Would `eq' be an operator only if it was
in an "operator position"? If not, then `eq' appearing outside would
have to be an error, breaking backwards compatability (!). If so, then
parsing is quite a bit harder, and unary operators become untenable: is
`plus(...)' a plus operator on the parenthetical expression or a call to
the method plus?

Furthermore, what is a candidate to be a potential operator? It seems
you might want + and -, but what about ±? §? ¢? ¤? — (not -)? ö? è? ß?
(There should only be two accented characters there; if not, change your
encoding to UTF-8.) In short, what characteristics would make a series
of characters potential operators?

notice that with mmodern environment like NETBean the eq is got
another color, so is well reading. I glad to hear another Idea, but
stay with this ugly code, is Stop java to reach more Developer. you
must think that code like "if(str1 eq str2)" is match faster that
existing str1.equal(str2).

How would NetBeans know that `eq' is an operator? It's also this point
that your text is throwing InternalParseErrors that I can't catch [1]...

Also if we thinking fresh, we can add directive to java compiler and
start new Java syntax, or Java Extended or what you like, but get Dev
free from narrow brain.. give us the freedom

You've not really added much on this subject. The following recent
thread had several different implementation ideas discussed:
<http://groups.google.com/group/comp..._frm/thread/c05f38c9e4c61b10/2b4ecbd2ad02b9ac>
An older thread that discussed operator overloading in more detail was
this one:
<http://groups.google.com/group/comp..._frm/thread/444250a94b1020c6/6b9b3d797281a3ff>

I've grown more in favor of operator overloading personally myself, but
I think even the strongest proponents would concede that there are very
few tools which can make code more indecipherable than operator
overloading. One has to balance expressiveness with potential for
misuse. For example, in some cases, it can be useful to overload the
comma operator, if you want to have a |matrix[row, column]| syntax or a
(really advanced) |"%s, %s" % (a, b)| sprintf-like functionality
(derived from python). That said, overloading the comma operator
irrationally leads you down the road to compiler hell. It's extremely
powerful but at the same time extremely easy to abuse.

[1] Sorry for the bad pun, I just couldn't resist.

 

[Chronic Philharmonic]

The "comparatively inefficient" String concatenation operator is
implemented by StringBuilder.

JLS 15.18.1.2
<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.18.1.2>

I wonder what a comparison would actually reveal.

It is theoretically possible that a Java compiler would not do that. If
you know of a real-world Java compiler that does not implement String
concatenation that way, send us the link, please.

I don't have a link. I am not by nature a "speculative optimizer". However,
I was given to understand many years ago, that because Strings are
immutable, each concatenation must create a new intermediate string, whereas
a StringBuilder is mutable, so it can simply modify the character buffer
within a single instance. It was therefore considered a best practice, if we
were concatenating more than three strings in a busy part of the program, to
consider using StringBuffer instead.