[943] in java-interest
Re: overloading of operators
daemon@ATHENA.MIT.EDU (Thomas Ball)
Tue Aug 15 19:55:19 1995
Date: Tue, 15 Aug 1995 08:51:05 -0700
From: Thomas.Ball@Eng.Sun.COM (Thomas Ball)
To: Tako.Schotanus@bouw.tno.nl
Cc: java-interest@java.Eng.Sun.COM
> I don't understand you guys at all! It's not as if *your* programs would be
> any worse off for just having a feature built into the language!
> And as for other people's programs, you're basically telling them "you can't
> use that feature because I don't like it".
It's apparent you have never had to support someone else's code. Using
operator-overloading, with the possible exception of new numerical
types, increases the cost of maintaining and supporting the code,
because it requires that you potentially learn a new language with each
class. If you want to write write-only code, use Forth (*that* statement
should start a religious war :-).
> I don't mind if we don't get operator-overloading, but if the Sun-people
> really listen too us on this list we'd better make sure we make our reasons
> for having or not having something are good ones.
If you mean the people driving the compiler changes, they aren't even
listening to their co-workers. Reason has nothing to do with it. (What,
me disappointed?)
> So for me: *I* like operator-overloading, I think that if you use it in a
> controlled way it can make your code more elegant, but that's a personal
> opinion for sure. But I might not be alone, I might be working for a
> company where it's "policy" to write code like that, and because everybody
> does it you don't have to worry that much about misinterpreting each others
> code.
It's a great waste of time: what's the "right" use of the '+' operator
in a graphics image? You can spend many otherwise fruitful days arguing
with your co-workers that it should mean and'ing the bits of the two
images, while they staunchly argue it means appending the two images.
It avoids real work, but what problem does it ultimately solve?
One thing few people have noticed is how Microsoft's Visual C++ team is
getting away with using a subset of the language. The MFC is probably
one of the best Windows C++ frameworks, and they don't use any overloading
in their 200+ classes. One reason they've stated they don't is that the
framework would be used by thousands of developers, and they wanted it to
be as easy-to-use as possible. If Java is to remain an easy-to-use
language, we should heed their advice.
> As for the fact that somebody else might find it difficult to understand my code,
> well to be honest (as long as I don't publish the code ;) I don't give a
> .......... (fill in your favourite rodent's backside).
I hope we never work together. You sound like a nice, intelligent person,
but I'd sure hate to be on a team that has a tight schedule with you. Code
is shared by the development team -- what happens if you get hit by a bus?
> I apologise if this is a bit rude, but I really think that it's nobodies
> business but mine to decide what features I'm going to use or not.
Someone needs to design, implement, test, and support these features. The
Java team is small, so that means other features will have to be cut to
support this one. What are you willing to give up?
> So shortly put: If there are NO compelling reasons NOT to have the feature
> we might as well considering putting it in for the people who want it.
>
> (Compelling reasons could be: performance problems even for programs NOT
> using the feature or even just that the Sun-people think it's too much work :)
I strongly recommend you (and everyone else) read the book, Writing Solid
Code, by Steve Macquire from Microsoft Press. Even those he works for the
dark side, Steve has an incredible grasp on how to write commercial code
which ships on-time and is reasonably bug-free. If everyone at Microsoft
followed his guidelines, we'd *all* be working for them, but thankfully
they still have lots of engineers with their heads in tight places.
Tom
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
