Re: operator overloading ... for numerical classes only
On Tue, 13 May 2008, Patricia Shanahan wrote:
Lew wrote:
Andreas Leitgeb wrote:
Mark Space <markspace@sbc.global.net> wrote:
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.
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.
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.
--
When you mentioned INSERT-MIND-INPUT ... did they look at you like this?