Re: polymorphic methods in O'Caml (fwd)

Re: polymorphic methods in O'Caml (fwd)

[Didier Remy]

> [ J'aimerais des methodes polymorphes dans le systeme d'objets. ]

C'est possible, mais cela reste a implementer.

> The problem I have is the following: I have methods that can be invoked on
> container widgets to add a widget into them. As methods can be
> polymorphic, and more specifically can't have a parameter of type
> #someclass, use of those methods has to include a cast onto the type
> "widget". This is inelegant (watch for the (xxx :> widget) expressions in
> the sample code included).

We are aware of this problem.  This is one of the (several) reasons that
motivated our investigation of first-class polymophism in ML [1].  Here, we
show that there is no theoretical problem at all. Technically, this requires
to trace some form of type sharing analogous to the one used for object type
aliases in O'Caml. In practive, it would provide polymorphic methods in O'Caml
in a quite simple way.

> Therefore, I'd like polymorphic methods to be implemented (even if it
> needs some explicit type declaration). 

To get a polymophic method you would need to explicitly give its
(polymorphic) type in the class where it is defined. 

Types of objects with polymophic methods would be inferred, but you would
also be required to explicitly write them when the context would not provide
sufficient type constraints,

This would not affect at all classes or objects that only use monomorphic
methods.

> Is there any reason why this couldn't be done?

We should certainly add this feature in some future version of O'Caml, but
nothing has been done yet.

    --Didier.

[1] Extending ML with Semi-Explicit Higher-Order Polymorphism.  Jacques
Garrigue and Didier Rémy.  In International Symposium on Theoretical Aspects
of Computer Software, volume 1281 of Lecture Notes in Computer Science,
pages 20--46. Springer, September 1997. URL
http://pauillac.inria.fr/~remy/publications.html

Re: subtyping and inheritance - correction

[Markus Mottl]

Hello,

in my last mail, I proposed the following rule for coercion of objects to
ancestors in the inheritance hierarchie:

  If an object that has inherited from another class is coerced to this
  class, then the definition *and* the type of all methods should be
  taken from this ancestor. Because the object *must* have all the data
  defined in its ancestor (it has inherited all of it), the use of the
  ancestor's methods should not lead to any inconsistencies.

This is not correct! In this case it would be impossible to make use of
virtual functions, which is, of course, not what I intend.

The correct rule should be:

  If an object that has inherited from another class is coerced to this
  class, then the definition of all methods
                  *** that mismatch in type ***
  should be taken from this ancestor...

My first proposition was a bit too general... ;-)

There are two cases in which this rule would be useful:

* Since the 'self-type is unique for every class, it would be impossible
  without this rule to coerce *any* descendant to *any* of its ancestors
  if the 'self-type has been used in them. This, although all methods
  of the ancestors could be safely applied to the object.

* It might also be in the interest of the programmer to "manually" use
  new types in a method that carries a name already found in ancestors.
  
If a method is called with parameters of types unknown to the object,
the compiler could try to find a matching definition in ancestors.
The first match found on traversal from bottom to the top would then be
taken.
This could actually give a polymorphic touch to the OO-part:
considering the example presented in the last mail, it would not even
be necessary then to explicitely use coercion. E.g. in

  a_terminal#compare a_symbol

the compiler could see that the "compare"-method in "terminal" does
not fit to parameters of type "symbol". It would look up definitions in
ancestors and see that there is a matching method in ancestor "symbol".


One of the downsides of this might be that the programmer could more
easily make mistakes - he might believe that the "compare"-method is
taken from "terminal", which is not the case. Still, the program would
type check correctly but behave different to the expectations of the
programmer...
I don't know whether this problem is severe. Because class type (in
general) is not explicitely stated, the programmer would have to verify
anyway, from which class the method is taken.

Strict separation of semantic properties (class types / interfaces) and
syntactic relations (inheritance) of classes probably provides for higher
security in programming and appears more elegant from a formal point of
view. But sometimes it doesn't seem to reflect the way the programmer
(only I??) thinks.
Since I am not an expert in class/type systems, it might well be possible
that my propositions are foolish. I have just tried to describe what
would appear natural in the use of objects to me... ;-)

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl