Related articles |
---|
Java static binding for parameters and covariance/contravariance lujoplujop@gmail.com (Lujop) (2004-11-19) |
Re: Java static binding for parameters and covariance/contravariance newsserver_mails@bodden.de (Eric Bodden) (2004-11-20) |
Re: Java static binding for parameters and covariance/contravariance vbdis@aol.com (2004-11-20) |
Re: Java static binding for parameters and covariance/contravariance mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2004-11-20) |
Re: Java static binding for parameters and covariance/contravariance lujoplujop@gmail.com (Lujop) (2004-11-26) |
Re: Java static binding for parameters and covariance/contravariance vbdis@aol.com (2004-11-26) |
Re: Java static binding for parameters and covariance/contravariance boldyrev+nospam@cgitftp.uiggm.nsc.ru (Ivan Boldyrev) (2004-11-28) |
From: | "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> |
Newsgroups: | comp.compilers |
Date: | 20 Nov 2004 21:22:23 -0500 |
Organization: | Compilers Central |
References: | 04-11-070 |
Keywords: | Java, design |
Posted-Date: | 20 Nov 2004 21:22:23 EST |
On 19 Nov 2004 00:53:07 -0500, Lujop wrote:
> I don't know if this is a little offtopic because is more a language
> question, but like languages and compilers are related to... Well,
> it's nice to have a moderator to decide this ;)
>
> I'm writing a compiler for a pseudocode language that also has to work
> as a translator to Java code. Then I am limited to Java features
> (extensions like multijava can't be applied) ...
>
> Java uses static binding for parameters. And only uses overriding when
> the signature of the method is the same (This is the invariant way,
> isn't it?).
>
> I think that the best way is to be able to use dynamic binding for
> parameters like (MultiJava extension) allows. But I can't do this
> because the restriction to generate Java code.
>
> Then my problem is that I thinked to use a contravariant way for
> parameters in my language. And don't allow to "overwrite" the method
> m(A) in class B with method m(B) where B<=A.
> And only allow to override parameters methods in a contravariant way.
>
> I think that this is less powerful, but it's more clear than Java and
> less error prone. Because in java when you "override" m(A) whith m(B),
> you are overloading (not overriding) and I think that is very confuse,
> and isn't very util, and very error prone. In fact Effective Java from
> one of Java library architects has a norm that says that you don't have
> do it.
>
> Then, my question is. What do you think that's better? What Java
> does, or what I proposed? Can you give my some readings about it? Are
> my terms correct (refering to covariance,contravariance and
> invariance?)
Better is to always make m(A) a method in A. This is how Ada 95 works:
if m is a method of A (= a primitive operation in Ada terms), then any
parameter of m of the type A is a subject of dispatch (= controlled in
Ada term). As such it is:
1) always covariant
2) to be overridden
For example:
type A is tagged ...;
procedure m (X : in out A; Y : A);
-- m is dispatching in both X and Y
type B is new A with ...; -- Derived from A
procedure m (X : in out B; Y : B);
-- overrides, covariant in X and Y
procedure m (X : in out A; Y : B);
-- illegal in the same scope as A
However Ada would allow the latter if B would be derived from A in
another package. In which case it would overload.
I agree with you that this behavior is error prone and should be
always illegal. Especially, because for contravariance Ada has a
concept of a class-wide type. That is for the example above:
procedure m (X : in out A'Class; Y : A);
Here m is a method in Y (=> covariant), but a "class-wide" in X (=>
contravariant). Ada allows overloading A'Class with A, B, B'Class etc,
which in my view is a design inaccuracy. I would not allow that under
any circumstances. So to me the rule of thumb is:
The language should not allow overloading A with B in a parameter if
there is a common ancestor C.
N.B. To be consistent this would also require an implementation of
multiple dispatch, which many OO languages seem trying to avoid at any
cost.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Return to the
comp.compilers page.
Search the
comp.compilers archives again.