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

A

Arne Vajhøj

Lew said:
The issue seems to be the preference for a brief notation like '==' (or
variant) in lieu of the currently spelled-out 'equals()'.

I read the excoriation of Java's designers in this thread for
"neglecting" to provide an operator for value equality as a tempest in a
teapot. They provided overridable '.equals()' instead, at a cost of 8
keystrokes per invocation (unless you use auto-completion in your IDE).
The explicit method invocation is, arguably, more readable, and
certainly more consistent with the notion that it is overridable.
Nowhere else in Java is the notion of operator overridability; they
would have had trouble making it happen just for operator 'equals'. In
fact, the presence of an overridable 'equals()' and 'hashCode()' in the
primordial 'Object' class is one key to Java's usefulness.

I confess that I am always nonplussed by some programmers' compulsion to
abbreviate code. I just don't find typing out 'equals()' so egregious,
and I do find its consistent presentation as a member method so
powerful, that the argument for ever more terse code is lost on me.

Less typing is not an argument for changing anything.

Increased readability can be an argument for changing something.

As soon as the code becomes mathematically inspired then I would
say that operators instead of method calls increase readability.

So there is a case for adding operator overload to Java.

The question is whether the benefits are big enough to justify
the added complexity to the language (fundamentally the simpler
the language is the better).

I am not convinced that is the case for operator overload.

But then I am not working with math stuff, so it is easy for me to say !

Arne
 
T

Tom Anderson

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?

Easy - it's !(a S b).
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?

I was about to agree with you, but then it occurred to me: could we just
let:

foo bar baz

Be sugar for:

foo.bar(baz)

? Would that break anything? I don't think there's a time where it's legal
to have three identifiers in a row with only whitespace in between like
that in current java, so i think, but am far from sure, that it would be
okay. It could create a bit of a parsing nightmare with:

foo bar baz qux quux

meaning either of:

foo.bar(baz).quz(quux)
foo.bar(baz.quz(quux))

But that just means you'd need a precedence rule of some sort, or treat
that as an error.

It would only be a minor bit of sugar, but it could help reduce the morass
of parentheses i sometimes find myself getting mired in. Still, it's
weird-looking enough that i wouldn't be upset if we didn't have it.
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?

Propose 'em all and let the JCP sort 'em out!
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]...

Quite. There's clearly no way that 'eq' could be recognised as an operator
rather than a variable name on its own, and so i think mttc's proposal
falls down hard here. My scheme above might be an option. Might.
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.

Perl.

Oh, you mean Java code? Er, in that case, J2EE.
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

What? No. You just define the [] operator as taking two arguments:

class Matrix<E> {
public E operator[] (int x, int y) {
return get(x, y) ;
}
}
or a (really advanced) |"%s, %s" % (a, b)| sprintf-like functionality
(derived from python).

I think i see what you're getting at, but again, no. I assume you're using
, as a way to construct tuples which could then be passed to the %
operator on the string, but that would mean implementing it on whatever a
was, and since that needs to range over any kind of object, that's not
going to fly. Unless you just define it in Object.

You'd either need to introduce Python tuple syntax to the language, or
just use arrays:

"%s %s" % new Object[] {a, b}

Or allow an elided array notation:

"%s %s" % {a, b}

Or make the % operator bracketing, like [], so it could take multiple
arguments:

"%s %s" %(a, b)

With:

class String {
public operator%() (Object... args) {
return sprintf(args) ;
}
}
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.

Yes. I'm adding it to my list of ur-operators which must not be
overloaded. Along with ; - you can effectively overload that in haskell,
but it involves turning the universe inside out, and has driven some fine
minds completely mad.

tom
 
M

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.

we can agree on new operator like (str1 eq str2)
 
M

Mark Space

Tom said:
I was about to agree with you, but then it occurred to me: could we just
let:

foo bar baz

Be sugar for:

foo.bar(baz)

I think you need some sort of operator there. "foo bar baz" is too close
to something that might be typed accidentally, and I'd like my compiler
to be able to spot obvious mistakes.

foo #bar baz

might work. I can't think of anything that uses # for an operator in
Java, so it's free and clear, and it stands out well when reading the
code too.

I'm also in favor of allowing some special compilers or script engines
to emit code directly into method bodies or static initializers.
Something like

public BigDecimal myMethod( BigDecimal d ) {
BigDecimal retValue;
@<script="scripEngine">
retValue = d * 2;
@</script>
return retValue;
}

This would solve a lot of problems for the specialized language folks,
while not directly adding to the base language itself. And it might
also simplify life for the compiler folks (at Sun), since they can just
punt the complexity over to someone else and let them handle it.


In other news, allowing inline operators (not sure if that's the right
word? the + - / * ones) for BigDecimal and BigNumber are apparently out
for Java 7. Something about too much complexity. Bummer.
 
P

Patricia Shanahan

bugbear wrote:
....
Operator overloading does indeed make code
involving arithmetic classes nicer, but since
code of this nature is normally conceptually
simple anyway, I don't see the strong
motivation to make easy code easier.
....

We must have read very different engineering and scientific programs.
Some of the ones I've read had complex number expressions that were hard
enough to follow and check against the original mathematics with infix
operators. Without, it would be practically impossible.

Patricia
 
M

Mark Thornton

bugbear said:
Tom Anderson wrote:
Operator overloading does indeed make code
involving arithmetic classes nicer, but since
code of this nature is normally conceptually
simple anyway, I don't see the strong
motivation to make easy code easier.

A lot of it is anything but simple, and in this field the absence of
operator overloading does obscure the intent. Nevertheless I concede
that it is very hard to confine the use of operator overloading to the
numerical classes where its value would be unambiguously positive.

Mark Thornton
 
J

John W Kennedy

Patricia said:
bugbear wrote:
....
....

We must have read very different engineering and scientific programs.
Some of the ones I've read had complex number expressions that were hard
enough to follow and check against the original mathematics with infix
operators. Without, it would be practically impossible.

In addition to extended (big or complex) arithmetic, I have sometimes
found that the easiest way to model something was to describe it as an
abstract group.


--
John W. Kennedy
"The bright critics assembled in this volume will doubtless show, in
their sophisticated and ingenious new ways, that, just as /Pooh/ is
suffused with humanism, our humanism itself, at this late date, has
become full of /Pooh./"
-- Frederick Crews. "Postmodern Pooh", Preface
 
T

Tom Anderson

In addition to extended (big or complex) arithmetic, I have sometimes found
that the easiest way to model something was to describe it as an abstract
group.

....

Could you share an example? I love group theory, but have never managed to
find anything to apply it to!

tom
 
J

John W Kennedy

Tom said:
....

Could you share an example? I love group theory, but have never managed
to find anything to apply it to!

Well, the most interesting one was translating a physical inventory of
IBM 3270 terminals, taking in machine numbers, model numbers and add-on
feature numbers, and outputting options needed to be known by software,
such as: "24x80 screen, programmable color, two user-programmable fonts,
numeric keypad embedded in alphabet keys". Different machines/models had
different default option sets, different feature codes implied different
combinations of usable options, and some feature codes on some models
implied the /removal/ of a option that was there by default. In
addition, the logic had to be data-driven, because any given Tuesday a
new Announcement Letter from IBM could add new complications. I
implemented it with something vaguely similar to a Java BitSet, but with
vectors of six-value logic atoms, rather than mere bits. (This was where
the group theory came in.) It was back in the mid 80s, so I don't
remember much of the details. I was coding in PL/I (and I used some PL/I
macros for syntactic sugar), but was, to some degree, thinking in Ada,
and wishing that PL/I had operator overloading.

--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
 
J

John W Kennedy

Lew said:
Most people who used PL/I wished they had anything else, AIUI.

I never had the pleasure, myself.

It has some grave faults (most of them, though, visible only in
hindsight), but, for decades, if you wanted a language (other than
Assembler) fully supported on IBM mainframes (i.e., officially supported
by databases, graphics packages, etc.), with...

block structure,
pointers,
threading,
any kind of variable but static,
bit handling,
variable-length character strings and substrings,
recursion,
or just almost any other post-1960 feature,

....PL/I was the only game in town. The alternatives were COBOL, FORTRAN,
and Assembler.

--
John W. Kennedy
"You can, if you wish, class all science-fiction together; but it is
about as perceptive as classing the works of Ballantyne, Conrad and W.
W. Jacobs together as the 'sea-story' and then criticizing _that_."
-- C. S. Lewis. "An Experiment in Criticism"
 
L

Lew

Andrea Francia
"Fortunately" because you are a overloadable operator opponent.

That's an interesting statement not based on evidence. When have I
ever spoken against operator overloading?

What I was speaking against was the introduction of creating only one
single, exceptional place in Java where there would be operator
overriding (not overloading) as something different from the rest of
the language. I would not express the same reservation about a
consistent language-wide introduction of such a feature. Setting up
an opinion I do not hold and shooting that down in an attempt to
invalidate my argument is known as the "straw-man" fallacy.

No one "question[ed] someone else's spelling".

It is standard practice when substituting a paraphrase in an exact
quote to put that paraphrase in square brackets. Oh, please forgive
me, great arbiter of netiquette, if I wasn't quite able to bring
myself to quote a (mere) typo exactly. No criticism of anyone's
grammar was expressed.

But I guess if you're in the mood to pick on someone ...
 
L

Lew

why? eclipse has a very good search&replace feature :)

That's not relevant. First, Eclipse is not the only IDE in the
world. Second, people don't even always use IDEs. Third, and much
more important, projects shouldn't have to go back and rewrite
everything from fifteen years of Java programming history because the
language suddenly changed its most fundamental operator. Even were a
good "search&replace feature" available to everyone, that's a
ridiculous cost to impose on the entire Java community for no good
reason. Many projects would have no budget for such a specious
change.

Some languages use "=" for equality comparison, some use "==", some
use ".eq.". There is no inherent value in one symbol over another -
each language chooses its own symbols. Pushing for such a change is
pointless - just use the symbol that the language defined and don't
insist that it match another language.

As to adding an operator for value equality, it is unlikely that the
powers that be will view the benefit as worth the disadvantages of yet
another change to the language, especially one that fundamental.
 
P

Patricia Shanahan

matu said:
it looks like you are scared of your knowledge :)

Not in the least, but neither am I scared to acknowledge the existence
of competent developers who disagree with me.

Patricia
 
P

Patricia Shanahan

matu said:
why? eclipse has a very good search&replace feature :)

What do you see as the overall flow for making the change? Presumably
"==" would have to be deprecated for a few JDK versions to make sure all
existing uses are replaced with "===" before the meaning of "=="
changes. How many versions do you think would be enough?

Patricia
 
P

Patricia Shanahan

Lew wrote:
....
As to adding an operator for value equality, it is unlikely that the
powers that be will view the benefit as worth the disadvantages of yet
another change to the language, especially one that fundamental.
....

I'm not sure it would be that big a change. We already have one
operator, "+", whose behavior depends, in some cases, on a specific
user-definable method, toString(). I don't see any difference in
principle between that and have an operator whose behavior depends on
equals().

Patricia
 
A

Andrea Francia

Lew said:
Andrea Francia

That's an interesting statement not based on evidence. When have I
ever spoken against operator overloading?

When I said that operator should be overloaded?
Probably you know better than me what I think.
What I was speaking against was the introduction of creating only one
single, exceptional place in Java where there would be operator
overriding (not overloading) as something different from the rest of
the language.

I never say nothing about the fact this should be added, or this should
be the single opertator to be added.

I only suggested an operator different form "===".
No one "question[ed] someone else's spelling".

It is standard practice when substituting a paraphrase in an exact
quote to put that paraphrase in square brackets. Oh, please forgive
me, great arbiter of netiquette, if I wasn't quite able to bring
myself to quote a (mere) typo exactly. No criticism of anyone's
grammar was expressed.

Seems to me that that sole purpouse of that brackets was to point out a
spelling error.
 
A

Andreas Leitgeb

matu said:
why? eclipse has a very good search&replace feature :)

After the other followups, I'm surprised how anyone could
really miss the smiley. It would even have been visible
in absence.
 
R

Roedy Green

This comes up periodically and the consensus is we don't want them.
They are so badly abused in C++ that overwhelms the benefits.

On the other hand I would consider user operators, but not with names
that overload the primitives. In other words use circle + instead of +
for your new operator for adding triangular matrices. Overloading
your own operators would be ok, with me, but not the primitives,
ESPECIALLY in idiotic ways like making >> do I/O.
 
P

Patricia Shanahan

Roedy said:
This comes up periodically and the consensus is we don't want them.
They are so badly abused in C++ that overwhelms the benefits.

Who is "we"? I know it does not include me.

C++ suffered from a special problem, being the first very widely used
language to support them. There was a lot of experimentation, with some
of the experiments leading to understanding of what things operator
overloading is *not* good for.
On the other hand I would consider user operators, but not with names
that overload the primitives. In other words use circle + instead of +
for your new operator for adding triangular matrices. Overloading
your own operators would be ok, with me, but not the primitives,
ESPECIALLY in idiotic ways like making >> do I/O.

I strongly disagree with the first couple of sentences. The single thing
that operator overloading would do well is allowing more natural-looking
code for non-primitive arithmetic. Using anything other than "+" for
addition is just as unreadable as using "+" for something other than
addition.

It is too late to keep the language designers from bad operator
overloading. String concatenation is not addition, and should not be
represented by "+".

Patricia
 
A

Andreas Leitgeb

Lew said:
The smiley completely, utterly, miserably and devastatingly failed to make the
comment into a joke.

Indeed: how could any smiley make a joke out of a joke?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top