[537] in java-interest
Re: Operator overloading
daemon@ATHENA.MIT.EDU (Henri BROUCHOUD - FT.CNET/LAA/EIA/)
Thu Jun 29 06:41:00 1995
Date: Thu, 29 Jun 1995 11:52:44 +0200
From: "Henri BROUCHOUD - FT.CNET/LAA/EIA/AIA" <brouchou@lannion.cnet.fr>
To: java-interest@java.sun.com
Sorry I don't actually understand where goes this discussion ...
It seems to me that there are no differences between method or
operator definition other than syntactic. All the problems, ambiguities,
obscurity that you can introduce with operators can be introduce
with methods too.
> then you really need
> a degree in pure maths to work out the group theory for any non-trival
> classes that you want to use these features for.
>
> If it looks like * it needs to act like *, so the group of all your
> classes instances needs to be reflexive, transitive, have a unity
> instance etc. etc.
??? You give your defined operator the semantic you want (like any method
behavior), and why should it be a transitive group ?? .
In the string class : S1 + S2 ( = S1.append(S2)) is certainly not
the same as S2 + S1 ( = S2.append(S1)) ! And S1 * S2 has no sense !
I don't think the meaning of "operator" in programming language is the
same as in group theory.
Moreover ,
You always can write bad code with any language you use, and
it is the programmer's responsability to write clear and maintainable code.
With the same reflexion you could say : Why introduce <procedure> concepts in
modular language such as Pascal and others since you can write :
procedure _67JJUlo__90 ( LI89 : integer, _$YU7_ppOL :real) ...
which can introduce a lot of obscurity on what this procedure actually does .
Same for multiple inheritance ...
Introducing a new language on the market suppose to provide more than what exists
today , not to be restrictive ! If _I_ consider that operator definition makes my
code "obscure", _I_ will not use this feature, this is _MY_ responsability to take
such a decision (that's what I do today with C++).
On the other side if I _NEED_ operator definition for some reason of mine, I will not
use Java but C++ or other ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Henri Brouchoud Tel : (+33) 96 05 10 30
CNET LAA/ EIA AIA Fax : (+33) 96 05 37 84
2, Route de Tregastel
22301 Lannion
FRANCE Henri.Brouchoud@lannion.cnet.fr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
