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