Re: Java static binding for parameters and covariance/contravariance

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
20 Nov 2004 21:22:23 -0500

          From comp.compilers

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)
| List of all articles for this month |

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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.