operator overloading

[Andreas Leitgeb]

I've seen code where the use of cryptic, extremely short variable names hurt
readability. I bet you have to (plural "you"). That shows that it is
possible to have too few characters in a source line to help maintainers.

I cannot parse the second sentence. My brain tells me: "unexpected EOS".

Apart from that: yes, I agree: there are cases, where too few chars do
hurt a lot.

We seem to disagree on whether overloadable operators would change from
"too many chars" to "good", or from "good" to "too little chars".

PS: both would happen, but I weigh occurrances of first more than
those of the second.

 

[Andreas Leitgeb]

There are plenty of cases on mathematics where the traditional
identifier is very short --- usually a single Greek letter. In languages
that permit such identifiers there is little to be gained by using
epsilon instead of ϵ.

The greek letter epsilon is actually "ε" and indeed perfectly legal
in Java, when using some unicode (or specifically greek) encoding.

It's one of those parts, where Java is *very* permissive beyond
all recommendations (which discourage use of international letters)

So, in the end, there is very much gained by using "epsilon"
(or "eps") instead of either ϵ or ε: portability to non-unicode
systems and ease of maintenance for people who do not have these
chars directly on their keyboards.

PS: I fear more that people may already use international characters
in their code, than what they'd do if they had operators to overload.

Object ο; // This ain't ηο "o"!

 

[Arne Vajhøj]

They had an arithmetic if statement (from memory)

if(expr)labelNeg,labelZero,labelPos

The target label depended on the value of the expression. If negative
the first label was used, zero the second and positive values used the
third target. All the labels were of course integers.

I know how Fortran arithmetic if works.

But I still think it must have been a bloody nightmare to
program.

The Fortran 77 code:

IF(I.EQ.1 .AND. J.GE.1 .AND. J.LE.3) THEN
K = 3
L = 4
ELSE
K = 5
L = 6
END IF

would be:

IF(I-1) 400,100,400
100 IF(J-1) 400,200,200
200 IF(J-3) 300,300,400
300 K = 3
L = 4
GOTO 500
400 K = 5
L = 6
500

That is worse than Basic.

But then of course the alternative to Fortran in 1957 was
assembler, so ...

Arne

 

[Mark Space]

1) and 2) are (imo) that "someone"'s own problem. If this
"someone" is not writing for his own joy, then he'd have
> to follow some guidelines, anyway.

Primarily I think a variation of #2. That someone, will out of
ignorance mis-design grossly. And they could do it while still
following guidelines. The potential for ignorance at a large
organization is very real too.

Not so much 1, 3 and 4.

If you cannot rely on the users of a prog-language, you (in the
role of a prog-language-designer) should instantly stop designing
any prog-languages.

I think though that there are indeed mis-features of programming
languages. That operator overloading has not been included in Java
already says (I think) Sun believes this also. I do not think they
should stop designing Java, and I won't stop contributing either. Sorry
about that.

Because *not everything* in it was bad.

What I'd really like to see is a little more discussion of what
specifically was right about it. I think we've degenerated a little too
much into "yes it is" "no it isn't" and we're not making headway on
anything resembling consensus.

Here's another idea: let's say Sun allows overloading +, -, /, and *
only... on certain classes. Only classes derived from java.lang.Number.
That'll stop people from applying overloading inappropriately to
random parts of their design.

I realize this may be too restrictive for you, but I offer it as a way
to further discussion.

Generating new classes for each legible calculation on BigIntegers ?
Strikes me as odd.

I honestly don't understand this comment. I think perhaps there is a
typo? Or I'm really lost...

Good luck! I prefer tried and tested "not-all-that-mis"-features.

You and I just disagree on this point. It might be helpful to find some
way to agree on something.

 

[Mark Space]

Neither having nor not having operator overloading is risk free. The
question, on which reasonable people can disagree, is which carries the
higher cost.

Right. So the important thing I think is to admit that we disagree, and
try to find some ground where we might agree.

Is there anything less that full C++ style operator-overloading that
would meet your current requirement? There's a fair number of
operations on matrices that don't use the simple style of algebraic
operators that simple numbers use. (My poor little brain strains to
remember them, however.) Should we look for a way to include those
notations, and may be extend that to more maths?

Can we have some set of operators that you feel you really need, and
some that would be just "nice to have?" Are their any that you
definitely do not need to overload?

 

[Volker Borchert]

Arved Sandstrom wrote:

|> A classic case of short variable names is "Numerical Recipes in C" (or
|> FORTRAN for that matter).

AFAIR, with old time FORTRAN, only the first and last letters of variable
names were significant, everything in between was silently ignored.

 

[Arne Vajhøj]

Arved Sandstrom wrote:
|> A classic case of short variable names is "Numerical Recipes in C" (or
|> FORTRAN for that matter).

AFAIR, with old time FORTRAN, only the first and last letters of variable
names were significant, everything in between was silently ignored.

Not in Fortran IV / 66 and newer.

I don't know earlier Fortran.

Arne

 

[Arne Vajhøj]

Not in Fortran IV / 66 and newer.

I don't know earlier Fortran.

Well - as always it is possible to find thing son the net.

http://www.softwarepreservation.org/projects/FORTRAN/704_FortranProgRefMan_Oct56.pdf

claims that variables names are 6 letters without any mentioning of
loosing middle characters.

Arne

 

[Andreas Leitgeb]

Here's another idea: let's say Sun allows overloading +, -, /, and *
only... on certain classes. Only classes derived from java.lang.Number.
That'll stop people from applying overloading inappropriately to
random parts of their design.

I realize this may be too restrictive for you,

That's almost(*) the amount of overloading, that I'd be happy with.

I mentioned it in other subthreads a few times: only arithmetic
operations for scalar types.

The restriction to "scalar" types is meant to include complex numbers,
or even quaternions, but not vectors or matrices(in the mathematical
sense). If we added vectors, then the semantics of add and
multiplication would become ambiguous. (piecewise adding or
concatenating; cross-product or scalar product;...)

*: I agree on the restriction to numeric types. I wouldn't exclude
other ops, like % on BigIntegers or other ops on other classes if it
made mathemtical sense for them.

Maybe other participants in this thread would fancy C++'s philosophy
for Java, but I'm not one of those.

 

[Andreas Leitgeb]

Right. So the important thing I think is to admit that we disagree, and
try to find some ground where we might agree.

Arithmetic operations on numeric/arithmetic classes seems to be
just that ground. See the subthread with adapted subject.

Are there any that you definitely do not need to overload?

I'd suggest those boolean operators have no such need.
Multivalued logics are not widespread enough to justify it.

Bitshift operators could be useful at least for BigInteger.

Relation operators "<",">",">=",... would be fine too, to have
overloaded, but bear the danger, that their existence could invite
wrong expectations on "==" and "!=".

 

[Tom Anderson]

Right. So the important thing I think is to admit that we disagree, and try
to find some ground where we might agree.

Is there anything less that full C++ style operator-overloading that would
meet your current requirement? There's a fair number of operations on
matrices that don't use the simple style of algebraic operators that simple
numbers use. (My poor little brain strains to remember them, however.)
Should we look for a way to include those notations, and may be extend that
to more maths?

Can we have some set of operators that you feel you really need, and
some that would be just "nice to have?" Are their any that you
definitely do not need to overload?

We need +, -, *, /, %, and unary - for the various kinds of complicated
number. Also >, >=, <, <=; ideally, == and !=, but it's far too late for
that now. Maybe we need === and !== instead. Maybe not.

We need [] and []= (ie foo[bar] = baz) for composite things like matrices,
and possibly collections.

I'd quite like to be able to use &, |, and ^ on sets. Possibly also &=,
|=, ^=.

I'd like to be able to gently abuse | and ^ for vectors. If i have * as a
dot product, i can use ^ for cross product and | for the resolute.

So (with assigning forms being implied):

essential: +, -, *, /, %, >, >=, <, <=, [], []=
nice: &, |, ^
i personally don't want: ++, --, !, ~, &&, ||, ternary operator
must not have: =, .

I'd probably throw ++, --, ! and ~ into the bag, just for completeness.
But leave the logical operators out.

tom

 

[Patricia Shanahan]

Patricia Shanahan wrote:
....

How do people feel about overloading "[]" and ".length", so that List
and array code would be more similar? An ordered sequence type would
provide implementations for ".length", "[]" as get(), and "[]" as set().

....

Another thought on this idea. Maybe the compiler should just map
".length" to size() and "[]" to get() or set() whenever one of them is
applied to a reference of type List, or any type extending or
implementing List. The methods are already guaranteed to exist, and to
have the necessary meanings.

Patricia

 

[Wojtek]

josh wrote :

operator overloading

I am reading this discussion and I shudder.

Can we not keep operator overloading out of the Java spec?

Using descriptive method names leaves no ambiguity as to what will
happen, whereas with operator overloading you need to make a best
"guess" at what the writer meant by the operator he/she chose for an
operation.

Yes, I have written in C++, and yes I have used operator overloading.
Unless you and the writer are in the same mind-set the only way to
ferret out what is happening is to dig into the source code.

Give me descriptive names every time. With modern IDEs long method
names are not the pain they used to be as the IDE provides code assist.

So rather than trying to "fit" a symbol into an operation, use a
descriptive method name.

To me operator overloading is one of those things that is neat to do,
somewhat like all the shortcut symbols in Perl, but it introduces huge
maintenance problems.

 

[Patricia Shanahan]

josh wrote :

I am reading this discussion and I shudder.

Can we not keep operator overloading out of the Java spec?

Using descriptive method names leaves no ambiguity as to what will
happen, whereas with operator overloading you need to make a best
"guess" at what the writer meant by the operator he/she chose for an
operation.

Yes, I have written in C++, and yes I have used operator overloading.
Unless you and the writer are in the same mind-set the only way to
ferret out what is happening is to dig into the source code.

Give me descriptive names every time. With modern IDEs long method names
are not the pain they used to be as the IDE provides code assist.

I actually strongly agree with this. The place where we differ is that I
feel that "+" is the most descriptive, clearest symbol possible for
arithmetic addition. Using it for anything else, including String
concatenation, is just as bad as using a misleading method name.

The challenge I presented earlier in this thread is a *very* simple
example of a mathematical formula:

"Consider calculating the sum of the first n terms of an arithmetic
series, given its first term, a1, and common difference, d.
http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29

Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."

Can you produce a descriptive method name form of this expression that
is as obviously equivalent to the original formula?

Patricia

 

[Wojtek]

Patricia Shanahan wrote :

The challenge I presented earlier in this thread is a *very* simple
example of a mathematical formula:

"Consider calculating the sum of the first n terms of an arithmetic
series, given its first term, a1, and common difference, d.
http://en.wikipedia.org/wiki/Arithmetic_progression#Sum_.28arithmetic_series.29

Infix arithmetic operator version: (n * (2*a1 + (n-1)*d))/2."

Can you produce a descriptive method name form of this expression that
is as obviously equivalent to the original formula?

Ok, this appears to be used as a utility method, therefore I would make
it static with the method returning the result of the formulae
calculation. The class could be named MyMath. So:

BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm,
termLimit, difference);

 

[Tom Anderson]

This balanced position, and others' similar posts indicate a possibility
that a restricted operator-overload mechanism for Java would gain general
acceptance, and that the discussion of how much to restrict the mechanism
would achieve consensus faster than a discussion of an "all" vs. "nothing"
implementation.

I agree. I don't think operator overloading should be taken to anything
like the degree it is done in C++. In particular, I would be strongly
opposed to overloading "=". Almost all the value lies in better
representation of arithmetic expressions whose operands are references
to immutable objects.

How do people feel about overloading "[]" and ".length", so that List
and array code would be more similar? An ordered sequence type would
provide implementations for ".length", "[]" as get(), and "[]" as set().

You will not be surprised to hear that i'm in favour of it.

I quite often find myself changing my mind about whether an ordered
sequence of data should be a List or an array. That can lead to warts
such as using Arrays.asList so that I can go on using get() and set()
even after turning it into an array. The refactoring would be easier if
I could use the same code for the operations they have in common.

Another option would be to have T[] implement List<T>, and behave like an
Arrays.asList list.

Maybe the solution is to make general provision in the language for
applying operators to objects, but none at all for defining overloaded
operators. Then make general provision in the VM for both. Sun [1] could
then apply magic to such library classes as it saw fit (String, the
primitive wrappers, BigInteger, BigDecimal, and some new general-purpose
Complex, Vector etc classes in java.math). This would give us the few
operatorable classes that are needed to cover 90% of all potential uses,
and wouldn't give ordinary programmers the ability to create new ones.

Those who desperately wanted to write overloaded operators would be free
to use a not-java, or not-quite-java, language that supports them and
compiles to java bytecode. But then they wouldn't be writing java. This is
exactly the situation we have now, where various languages supporting
operator overloading compile to bytecode.

The one thing this couldn't do is collections. If you add [] to List, you
have to give people a way to implement it. If List was an abstract class
rather than an interface, you could magic [] into the abse class and have
it punt to get, which people could implement. But it's not, so you can't.

tom

[1] The company, not the star.

 

[Mark Space]

Ok, this appears to be used as a utility method, therefore I would make
it static with the method returning the result of the formulae
calculation. The class could be named MyMath. So:

BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm,
termLimit, difference);

Oops. That was actually a really good answer.

 

[Mark Space]

Patricia Shanahan wrote :

Ok, this appears to be used as a utility method, therefore I would make
it static with the method returning the result of the formulae
calculation. The class could be named MyMath. So:

BigInteger seriesSum = MyMath.getProgressionSeriesSum( startTerm,
termLimit, difference);

Maybe, you know, document too...

public class MyMath {
private MyMath {}

/** Calculates the arithmetic progression for n terms.
*
* Uses the formula: (n * (2*a1 + (n-1)*d))/2
*/
public static double getProgressionSeriesSum( double startTerm,
double termLimit, double difference)
{
// ...
}
}

 

[Wojtek]

Mark Space wrote :

Maybe, you know, document too...

Well yes of course

I was just illustrating that the method name gave enough information,
plus that not all editing environments pop-up JavaDoc

 

[Wojtek]

Patricia Shanahan wrote :

I actually strongly agree with this. The place where we differ is that I
feel that "+" is the most descriptive, clearest symbol possible for
arithmetic addition. Using it for anything else, including String
concatenation, is just as bad as using a misleading method name.

Yes.

And the people at PHP agree with that as PHP string concatination is
done with a period.

It is too late to do anything about it though. Think of the millions of
LOC that would be affected...