[987] in java-interest

home help back first fref pref prev next nref lref last post

Re: overloading of operators

daemon@ATHENA.MIT.EDU (Tako Schotanus)
Wed Aug 16 08:01:01 1995

Date: Wed, 16 Aug 95 09:39:58 +0200
To: Terence John Parr <parrt@parr-research.com>, java-interest@java.sun.com
From: Tako Schotanus <Tako.Schotanus@bouw.tno.nl>
Cc: gary@Intrepid.COM, johnm@alumni.EECS.Berkeley.EDU

At 10:40 15-08-95 -0700, Terence John Parr wrote:
>Hi gang,

>This is how C++ started: never saying no to new features.  Remember just
>because you can do it, doesn't mean it's a good idea.  Ask yourself which
>of the following is easier to understand (yes, even you have
>to understand your code later):
>
>database.addRecord(foo);
>database += foo;

True, but on the other hand... I wouldn't use it for this :)
I just like to see A + B where A and B could be complex numbers or
matrices. But it seems I'm alone in this *sigh*

>> 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.
>
>The reason is simple: C++ is too complicated.  Java is not.  Let's keep
>it that way.

Hmmmm, but C++ *forces* that complexity on you, I mean, a lot of times you
can't get around it with all the virtual destructors and stuff. Like they
once said in an article: To do the same thing in Smalltalk and C++ you'd
have to be a better C++-programmer.

>As a person who's life revolves around implementing language tools, I
>must say you increase the complexity and difficulty of every Java tool
>with every addition.  At the moment, it's a no-brainer (well almost).
>
>I can send you my slides that I use to scare people when giving a talk:
>
>	"C++ Parsing (Or, How to induce heartattack)."

Would be nice *grin* (no need to *really* do it, though ;)

>> 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.
>
>That's right; so let's not allow features that can be so easily abused.

Well, that's a goodish reason, I think...

>
>> 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.
>
>The reasons are simplicity and readability (read that maintainability).

Well I think A + B where A and B are matrices *is* readable...

>I type fast and don't worry about a few keystrokes for readability.
>My variable names tend to be long.  For a good laugh you should see
>my translator I built for some Army code...it had function names
>like:
>
>	TraverseASTAndGenerateListOfImplicitlyDefinedScalars(AST *t);
>
>No doubt what *that* function does :).

Doesn't say what AST is though! ;)
But seriously, of course this is the way to do it and it's the way *I* do
it too (altough I've never gone as far as you =), but still there are cases...
but maybe you're right and it's not worth the effort to put it in for just
those (few?) cases...

>Better than a comment because I'll
>change the function name if its function changes, but programmers don't
>typically change comments. ;) ;)

Hmmm, so let's get rid of comments as well! ;)

- Tako
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/               Tako Schotanus, TNO Bouwinformatica                    _/
_/   work: Lange Kleiweg 5, 2288 GH, Rijswijk, NL, tel: +31-15-842393   _/
_/       home: van Hasseltlaan 352, 2625 HZ, Delft, The Netherlands     _/
_/     E-mail: sst@bouw.tno.nl - URL: http://huizen.dds.nl/~quintess    _/
_/ Never let a dictator rule with peace; let peace rule like a dictator _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com

home help back first fref pref prev next nref lref last post