Re: operator overloading
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---910079544-1313695486-1210327342=:25495
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <Pine.LNX.4.64.0805091102251.25495@urchin.earth.li>
On Thu, 8 May 2008, Owen Jacobson wrote:
On May 8, 8:10?pm, Tom Anderson <t...@urchin.earth.li> wrote:
On Thu, 8 May 2008, Owen Jacobson wrote:
On May 8, 1:52?pm, Tom Anderson <t...@urchin.earth.li> wrote:
You could even model a little hierarchy on discrete mathematics: Addable,
Multipliable, Ring extends Addable, Multipliable, Dividable, Field extends
Ring, Dividable, etc.
The question is, at the language and standard library level, do you
provide four interfaces (for +, *, /, and -) or one (for all four) or
five (both) or some other combination?
It's worth looking at the way Haskell handles operator overloading and
numeric types here. [SNIP]
Thanks for that. It sounds a bit like Smalltalk's hierarchy, only a bit
more rigorously thought out.
If you include every possible combination of operators in the standard
library, you end up with a huge number of mostly-useless interfaces.
Which is a pretty fair description of the standard library at present!
You've a call from the org.omg package complaining about unfair
representation. ;)
Aside from the "obvious" cases like CORBA support, there is very little
in the Java SE library that I would opt to remove. The XML support
could use some streamlining, perhaps; it's gotten overgrown as Sun has
gotten in the habit of declaring the XML library of the week to be
"standard" and adding it. So I suspect we disagree there, or are
thinking of different definitions of "standard library" (and if you
start including Java EE or other javax.* packages that aren't part of
the Java SE library, I'd certainly agree with you).
Much or most of the standard library is indeed pretty good. There are
patches where it's not, though - J2EE, XML, Swing. I often feel like i'm
jumping through hoops with java.io, but only when trying to mix
readers/writers and streams.
(And that doesn't even get into operators like ++ and +=; I'd probably
prefer to have +=, at least, implemented automatically in terms of +
instead of being its own operator, but it's not a clear choice.)
There are times when being able to override += would be useful, because
using + to synthesise it involves throwing away an object, and if they're
heavyweight, that's not great. If your objects are million-by-million
matrices, for instance, you'd really like to be able to add in place.
If your objects are million-by-million matrices, I would hope that you
have some kind of sparse matrix structure, or some other compositional
representation that doesn't actually hold all trillion elements in
memory simultaneously.
No, i'm doing weather simulations. Or handling terapixel images.
One thing we definitely shouldn't have is overriding of the = operator,
as C++ lets you do. That's just insane. Ditto the . operator.
No argument from me. The . and = operators only make sense in C++
because C++ has objects-as-values.
True. There are certainly positive things you can do with this power, but
it's still, IMHO, too much of a headache.
I'd add -> to the list (even though the Java equivalent is .), since
object indirection is a fairly core part of the language and I don't
want anyone monkeying with it.
It's that meaning of . i meant - java's ., which is C++'s ->. Java doesn't
really have a .. But if it did, i would want it to be overridable!
That said, python lets you override ., and it can actually be very useful
at times (making proxy objects and things like that). Without python's
dynamicity, it would be less useful, so i'm happy to leave it out of java.
As others have already suggested, a solution like
public interface Addable<A, S> {
?public S add (A addend);
}
with generic "S"um and "A"ddend types makes the most sense. ?It's
just, like so much in Java, unpleasantly verbose in the simple case --
a number-like class (for example, BigDecimal) would become
public class BigDecimal implements Addable<BigDecimal, BigDecimal>,
Comparable<BigDecimal>, ...;
Also, can i declare:
public class Vector implements Multipliable<double, Vector>,
Multipliable<Vector, double>, Multipliable<Matrix, Vector>
?
No, as double is not a reference type; no, as you can't implement an
interface more than once and all those generic specializations are
really the same interface. The former can be worked around with the
language as-is; the latter cannot.
In that case, i think any interface-based solution fails.
Allowing that would involve changing the way method overloads are
resolved, or adding rules to forbid implementing both
Multipliable<Double, Vector> and Multipliable<Vector, Vector> - as it
stands, you can't provide both public Double multiply (Vector) and
public Vector multiply (Vector) in the same class, because the only
distinction is the return type.
That's fair enough. I can't think of any approach to operator overloading
that would allow that without further language change. Overloading on
return type is the kind of thing perl would do.
--
[The sig that ate Manhattan...]
Jesus H! McQuary limit, anyone?
Apologies! I mostly have 1-3 line sigs, but i love that quote, and i
couldn't see any way to trim it down. So, once in a while, i indulge
myself and impose it on usenet. On average, my sig length is still well
under the limit, and probably shorter than most (most who have sigs, that
is).
tom
--
Annoying others means you are wise; it is when you annoy yourself that
you are truly enlightened. -- The Bullet Proof Monk
---910079544-1313695486-1210327342=:25495--