Re: Java static binding for parameters and covariance/contravariance

Lujop <lujoplujop@gmail.com> schreibt:


>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.


In Delphi (OPL) conflicting methods must be attributed explicitly as:
virtual - can be redefined in derived classes override - virtual
replacement for the ancestor class method of the same signature
overload - method with intentionally different signature reintroduce -
supersedes (hides) ancestor methods of the same name


You may add the Java "final" attribute, if you like.


Then your compiler can give detailed diagnostics on what's not allowed
with or without an according attribute. Now the user must make clear
to the compiler what s/he has in mind, and the compiler can oppose or
translate that intention into Java code, if ever possible. This way
you can e.g. enforce the use of different method names for methods
that otherwise would behave in an unwanted way in the Java
translation.


IMO you should eliminate all Java (target language) specific
implications from your language. You choose what can be translated and
should be possible to declare in your language. You'll have to prevent
unallowed, unexpected or ambiguous declarations to be syntactically or
semantically valid in your language. The user has to clarify what he
has in mind, in /your/ language and to /your/ compiler. Your compiler
can be more restrictive than really required, and e.g. require
different method names instead of silently changing the offending
names during the Java translation, so that the user will never see
different names during debugging.


DoDi

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