Hashtable

[Oliver Wong]

It is traditional in C-style languages.

& - reference and and
* - dereference and multiply
+ - addition and string concatenation (a non-commutative operation)
. - instance qualifier and decimal point
) - bracketing, indicating a function and end of if/while/for
expression.

Also % and ^ in Microsoft extensions to C++.

It is occasionally pointed out that although Java claims operator
overloading is bad (which is one of the reason Java doesn't allow operator
overloading), it's somewhat hypocritical that Java overloads the + operator
to mean both numerical addition and string concatenation.

So coming up with a new operator for string concatenation might be seen
as a way to fix this inconsistency.

- Oliver

 

[Thomas Hawtin]

Even you could, my whole reason to avoid + is so that you don't use
the same symbol for two unrelated purposes even if the compiler can
figure it out.

It is traditional in C-style languages.

& - reference and and
* - dereference and multiply
+ - addition and string concatenation (a non-commutative operation)
. - instance qualifier and decimal point
) - bracketing, indicating a function and end of if/while/for
expression.

- greater than and end of generic type list

Also % and ^ in Microsoft extensions to C++.

Tom Hawtin

 

[tuurbo46]

Hi

Thanks for your advice.

Im not next to the enviroment right now. I will get back to you
tomorrow.

Thanks again.

 

[Roedy Green]

So coming up with a new operator for string concatenation might be seen
as a way to fix this inconsistency

I'm fine with leave + the same in the canonical text files. I just
want to have an IDE display it differently, even if just a different
colour + for addition and concatenation to make errors stand out. Java
gets "confused" if you don't use enough ().

 

[Stefan Ram]

I'm fine with leave + the same in the canonical text files. I just
want to have an IDE display it differently, even if just a different
colour + for addition and concatenation to make errors stand out. Java
gets "confused" if you don't use enough ().

I a sense, there is another overload.

Some programmers (ab)use the "+" operator to convert
to java.lang.String, as in:

"" + 2

instead of

java.lang.String.valueOf( 2 )

So "+" could mean:

- numerical addition,
- string concatenation, or
- conversion to string.

However, I have no problem with all this. Human natural
languages tend to overload nearly every word with different
meanings, and polymorphism in OOP also might be considered as
some kind of "overloading" of a name with many ("poly")
implementations ("morphs").

So if it is used in natural languages and in OOP, why
should it be a problem when used for some operators?

 

[Stefan Ram]

"" + 2

There is also similar other bad way, to convert to String, namely,

"".valueOf( 2 )

 

[zero]

(e-mail address removed)-berlin.de (Stefan Ram) wrote in @ram.dialup.fu-berlin.de:

There is also similar other bad way, to convert to String, namely,

"".valueOf( 2 )

This is a side-effect of static factory methods. Perhaps it could be
overcome if language designers only allowed static methods to be called
with the ClassName.methodName() syntax, and not objectName.methodName().

Btw, I don't see anyone who knows a little about Java using the syntax you
mentioned, even if they are unaware of the performance hit.
String.valueOf() is more natural than "".valueOf().

 

[Andrew McDonagh]

(e-mail address removed)-berlin.de (Stefan Ram) wrote in @ram.dialup.fu-berlin.de:




This is a side-effect of static factory methods. Perhaps it could be
overcome if language designers only allowed static methods to be called
with the ClassName.methodName() syntax, and not objectName.methodName().

Btw, I don't see anyone who knows a little about Java using the syntax you
mentioned, even if they are unaware of the performance hit.
String.valueOf() is more natural than "".valueOf().

I had a terrible time trying to stop some of our devs doing "" + 2 or
"".valueof(2) most don't see the problem

and only see that its less keyboard typing...

like the thread on variable naming, where someone replied that I must
lilke keyboarding typing because I'd rather use a meaningful english
sentence, rather than negate the result of another method..

as in...


if( noMoreElements()

instead of..

if (! hasMoreElements())...



Typing away atthe keyboard is irrelvant... code and design clarity are
much more important.

Andrew

 

[Roedy Green]

So if it is used in natural languages and in OOP, why
should it be a problem when used for some operators?

I gave a reading comprehension test on this + ambiguity matter to room
full of high powered Java coders at a software conference. Most
failed.

See http://mindprod.com/jgloss/gotchas.html#CONCATENATION

 

[Oliver Wong]

I a sense, there is another overload.

Some programmers (ab)use the "+" operator to convert
to java.lang.String, as in:

"" + 2

instead of

java.lang.String.valueOf( 2 )

So "+" could mean:

- numerical addition,
- string concatenation, or
- conversion to string.

At the bytecode level, + is very heavily overloaded. It could be integer
addition, or long addition, or double precision floating point addition, or
single precision floating poitn addition. At the "Java" level, we usually
gloss over that, and just consider all those operations to be the same (even
though the algorithm could vary wildly, for example between integral
addition and floating point addition).

The "string concatenation" and "conversion to string" isn't two
different overloaded operations. Actually, when you do the string
concatenation, string conversion always occurs. So for example, the express
"Hello " + "world" converts its arguments to strings (which is trivial since
they are both already strings), and then does the concatenation.

However, I have no problem with all this. Human natural
languages tend to overload nearly every word with different
meanings, and polymorphism in OOP also might be considered as
some kind of "overloading" of a name with many ("poly")
implementations ("morphs").

So if it is used in natural languages and in OOP, why
should it be a problem when used for some operators?

1 + 1 + " foo" == "2 foo"
"foo " + 1 + 1 == "foo 11"

If you follow the rule of least astonishment, the above behaviour
shouldn't happen, because most people would be surprised by it. Why are they
surprised? Because they are confusing when + is performing numerical
addition and when it is performing string concatenation.

I'm not saying ALL operator overloading is bad; I'm just saying that
overloading an operator to perform both numerical addition and string
concatenation can lead to surprising behaviour.

- Oliver

 

[Stefan Ram]

1 + 1 + " foo" == "2 foo"
"foo " + 1 + 1 == "foo 11"
If you follow the rule of least astonishment, the above behaviour
shouldn't happen, because most people would be surprised by it.

Reminds me of the following example, which also involves "+":

public class Main
{ public static void main( final java.lang.String[] args )
{ java.lang.System.out.println( 1E20 + 1 - 1E20 );
java.lang.System.out.println( 1E20 - 1E20 + 1 ); }}