[1025] in java-interest
Re: overloading of operators
daemon@ATHENA.MIT.EDU (Tako Schotanus)
Thu Aug 17 01:55:57 1995
Date: Wed, 16 Aug 95 16:08:47 +0200
To: java-interest@java.sun.com (Java Interest Mailing List)
From: Tako Schotanus <Tako.Schotanus@bouw.tno.nl>
At 02:42 16-08-95 -0400, Futplex wrote:
>Someone whose original message never made it here, and whose name has been
>omitted by subsequent posters, writes:
't was me who it was ;)
>> 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.
>
>Oh my. You don't by chance work for a company that just released
>SuperWordWriter 8.2.7, a word processor that also balances your checkbook,
>computes digits of pi, routes TCP/IP packets, and cleans up after dinner ?
>
>IMHO this is a *major* mistake made by various hardware and software outfits.
>Adding complexity that you don't really need tends to make many people's
>lives more difficult.
*sigh* Here we go again:
I'm *not* saying that if you *can* do it, you should do it.
I'm saying that *if* it can be proved that adding a certain
feature or adding just too many features would in any way make peoples
lives more difficult that would be a compelling reason in *my* book.
The thing is, I have yet to see this proof for op-overl.!
The thing is that the company that you mention will probably be spending
more resources adding new features instead of fixing/improving old ones
because it sells better. Of course that's no good.
If adding a features would seriously degrade the performance of the
compiler and/or interpreter, that would be a reason as well not to add it.
These would all be "compelling reasons", but they don't apply here I think.
Sun can make out for themselves if they want to spend the resources on
this or that, so if they think they can spend the resources why not do it?
>I hope that Sun will KISS.
That's the x-th time I see that, can somebody explain what KISS means?
(Besides the obvious ;)
>Meanwhile, as I mentioned in a reply to someone else recently, you can't
>turn around without falling over heaps of languages packed with all sorts
>of funky features. How about we have at least a few languages that don't
>have maximal quantities of crud shoveled into them ?
Can you give examples of circumstances where aforementioned crud has
hampered your productivity or ability to write proper code?
>I don't see much merit in saying "Why not ?". I believe the burden of proof
>lies on your side: why do we *need* to add this stuff ?
Because it makes mathmatically oriented code much easier to understand
and it would be good when things that considered normal in mathmatics
could be "translated" 1:1 into code. (And not like in an earlier example
A.set(B.complexAdd(C.complexMult(D)) instead of A = B + C * D )
Of course, you might just not care for this, I do.
>That said, I don't have any religious objection to the abstract notion of
>operator overloading. I counsel heavy caution and conservatism in the
>selection of specific implementations of it / support for it.
Well, *that* goes without saying ;)
- 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
