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

[mttc]

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!

Sun Guys Wake up, dot leave us alone with battles against C# Guys!! We
want it Now on Java

if you want to not admit with this mistake, continue talk about the
complicity of "Operators overloading"
the Java is best, but do it!

 

[Nigel Wade]

comp.lang.java.advocacy us just around the corner, over there...

 

[Joshua Cranmer]

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!

I personally prefer if ("Hello".equals(s)) myself (it's sometimes a tad
more accurate).

In any case, /something/ needs to refer to pointer equality. If you
overload `==' as an alias for .equals, what would you use?

if you want to not admit with this mistake, continue talk about the
complicity of "Operators overloading"

Operator overloading is a double-edged sword. It really only makes sense
in context with mathematical operations; using it outside can have
unintended consequences (cf. C++'s usage of << and >> for stream
operators). "If they can use it, they will abuse it."

 

[mttc]

thanks for all.

but again, the most time we do == for string we mean to content, so is
better to use with another syntax when you looking for pointer
compare.

And as I say before, all dev know that Operator Overloading is nice
thing
But SUN guys have difficult to admit it, and Give us this Now, and who
is think that there is problem, can continue stay on darkness..
and for null situation what your solution for Equal? same solution
apply to ==

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

Like I say before:

but have another way: add to java another way

 

[Patricia Shanahan]

mttc wrote:
....

And as I say before, all dev know that Operator Overloading is nice
thing

....

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.

There are many developers who appear, from their postings here, to be
knowledgeable and experienced and who believe that the cost of misuse
leading to unreadable code would be higher than the benefit of being
able to use infix operators to represent arithmetic operations.

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.

Patricia

 

[Tom Anderson]

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.

No it isn't.



tom

 

[Tom Anderson]

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!

Sun Guys Wake up, dot leave us alone with battles against C# Guys!! We
want it Now on Java

if you want to not admit with this mistake, continue talk about the
complicity of "Operators overloading"
the Java is best, but do it!

I'm with you.

You're going to catch a lot of flak for suggesting it in this, group,
though: it's a mire of kneejerk anti-operator-overloading bigotry. Here,
most people believe that operator overloading is a terrible sin which will
cause the end of the world.

Of course, it works perfectly well, without any apocalyptic side-effects,
in Smalltalk and Python, but none of the overloadophobics want to talk
about that.

tom

 

[mttc]

mttc wrote:

...> And as I say before, all dev know that Operator Overloading is nice

...

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.

There are many developers who appear, from their postings here, to be
knowledgeable and experienced and who believe that the cost of misuse
leading to unreadable code would be higher than the benefit of being
able to use infix operators to represent arithmetic operations.

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.

Patricia

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!

 

[mttc]

Tom Anderson, how we convince java guys to change his mind? we must
resolve this problem..

 

[Joshua Cranmer]

And as I say before, all dev know that Operator Overloading is nice
thing
But SUN guys have difficult to admit it, and Give us this Now, and who
is think that there is problem, can continue stay on darkness..

Operator overloading is /extremely/ controversial. It's syntactic sugar,
but a sugar that can easily lead to unreadable gops of code. You know
that '>>' is so obviously a stream redirection; perhaps I might be
clever and overload the operator for the `&' operator (more likely the
`&=' operator) to set a flag on an object.

The only cases where operator overloading tends to be unambiguously
positive is in the instance of number and number-like classes, such as
BigInteger or maybe a Complex<Integer> class. Matrices or other
higher-order mathematical classes might benefit form operator
overloading, but I can see arguments against those. But those are the
only cases which tend to enjoy a fair amount of support.

Something a tad more controversial is overloading [] for lists and maps,
similar to the C++ STL. This has been discussed at least once, maybe
twice, in the past year on this forum.

Indeed, for a more in-depth analysis on the topic, read the numerous
threads on this topic, including notably a few examples of how it might
be implemented and a detailed discussion on how LHS primitive-Object
overloading might be accomplished. My personal stand on the
topic--nuanced as it is--can be derived from these earlier threads,
particularly the one I started.

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

There are some who dislike the choice of `+' as a concatenation
operator, since it can easily make someone multiply a number by 10 and
then add 1 instead of adding 1 to it.

 

[Patricia Shanahan]

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?

The obvious case is the first line of the equals(Object) implementation
in java.lang.String. Everyone who has ever done a String .equals test
has used "==" to check for identical objects, whether they know it or not.

Patricia

 

[Tom Anderson]

Did you leave C++ out of that list be accident or design ?

By design. And also C# - i'm not familiar with it, but i have heard
rumblings of operator overloading calamities over there too.

You're bang on to pick up on that omission, of course. Things *did* go
horribly wrong with operator overloading in C++. But they haven't in
Smalltalk or Python, and thus the common objection to operator
overloading, that it leads inevitably to bad code, is flat-out wrong.

If operator overloading was introduced into Java, or to some future
post-Java language, it would be vital to study both Smalltalk/Python and
C++/C#, and figure out what it was that made operator overloading work in
one and fail in the other.

My feeling is that it was the example set by the standard library
designers: C++ used << and >> for reading and writing with streams (which
i think is a pretty bad idea), some of the most basic operations of the
language, and ones which everyone learning C++ will come across almost
immediately. That set a tone for the misuse of operators which was echoed
in other libraries. ISTR that the STL also does some evil things with
operators. Furthermore, C++ made even the most fundamental operators -
assignment and member access, the quarks of the language - overloadable,
and this makes it very easy to write very, very surprising and
hard-to-understand code. In C#, things are better, but i see that some
bright spark decided that += was a good name for the method to add an
handler to an event source. Again, this sets a tone for silliness with
operators.

In Python and Smalltalk, on the other hand, there's none of this. In
Python, arithmetic operators are defined on arithmetic objects like
numbers and matrices; addition is also used for concatenation of lists and
strings, the logical operators are used for operations on sets, quite a
few things have comparison operators, and almost everything container-like
supports the [] operator. There are some slightly funky things, like
multiplication being defined on strings and lists (so "a"*3 is "aaa"). But
there's nothing in the standard library that i'd call operator abuse. I
haven't seen operator abuse in third-party libraries, and i think that's
because of the example set by the standard library.

So, if operator overloading was introduced into Java 3000, as long as its
use in the standard library was carefully controlled, i think we'd have a
good example for users to follow and we wouldn't see abuse of it.

tom

 

[Tom Anderson]

Tom Anderson, how we convince java guys to change his mind? we must
resolve this problem..

No. People don't change their minds. We have to learn to accept that Sun
and most of our fellow programmers don't want operator overloading, and
live without it. That's not very hard - it's a pretty minor feature, all
things considered.

tom

 

[Tom Anderson]

It already did, but no one noticed because they were voting for their
favorite /Idol/.

"There is a theory which states that if ever anyone discovers exactly what
the Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable. There is another
theory which states that this has already happened." -- Douglas Adams

tom

 

[Tom Anderson]

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?

I think Patricia's point is that == is already usd for identity, ie
pointer-to-pointer, comparisons, and thus that allowing it to be
overloaded would introduce confusion. I think she's absolutely right on
this. If you're going to allow an overloadable operator to be used in
place of the equals method, it would have to be something new - ===,
perhaps.

If i was starting from scratch, i'd define == to be the overloadable
equality operator, and === to be the non-overloadable, primitive, identity
operator. But it's too late to do that now.

tom

 

[Bent C Dalager]

(...) There are some slightly funky things, like
multiplication being defined on strings and lists (so "a"*3 is "aaa").
(...)

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?

Cheers,
Bent D

 

[Daniel Pitts]

thanks for all.

but again, the most time we do == for string we mean to content, so is
better to use with another syntax when you looking for pointer
compare.

Most of the time when *you* do ==, ... Please don't speak for the whole
of Java programmers.

And as I say before, all dev know that Operator Overloading is nice
thing

I happen to think that Operator Overloading would be a good thing, but
your argument is flawed.

But SUN guys have difficult to admit it, and Give us this Now, and who
is think that there is problem, can continue stay on darkness..

Java is what it is. Don't abuse the creators until you've created your
own language.

and for null situation what your solution for Equal? same solution
apply to ==

So, == would get an NPE? How do you find out if it is null then before
testing for equality?

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

Actually, I think "+" was the wrong symbol to choose. I would have gone
with "#" probably. str1 # str2.

Like I say before:


but have another way: add to java another way

I don't think == should be overloaded/overloadable. Java programmers
know to always use ".equals".

However, for algebraic operations, I agree that overloading should be
available.

 

[Daniel Pitts]

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 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]

I'm with you.

You're going to catch a lot of flak for suggesting it in this, group,
though: it's a mire of kneejerk anti-operator-overloading bigotry. Here,
most people believe that operator overloading is a terrible sin which
will cause the end of the world.

Of course, it works perfectly well, without any apocalyptic
side-effects, in Smalltalk and Python, but none of the overloadophobics
want to talk about that.

tom

I disagree with you on almost everything in your post.

The one exception I make is for algebraic operators and for "index"
operations ([] specifically) 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.

 

[Patricia Shanahan]

mttc wrote:
....

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!

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.

In general, changes to the meaning of an existing construct are much
more dangerous and confusing than giving a meaning to something that
would currently cause a compiler error.

To avoid breaking existing code that uses "==" for String identity
comparison, you would presumably need to make the meaning of "==" for
String depend on some form of context. Readers would have to be aware of
whatever controlled whether "==" meant content or identity comparison.

That is very different, and much less clear, than using a combination of
type and operator for which there is no currently defined meaning. For
example, I would like (a + b) for BigDecimal a and b to mean the same as
a.add(b), regardless of where it appears. That cannot break any existing
code.

Patricia