[987] in java-interest
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