Date: Mon, 23 Jun 1997 11:46:04 +0200
Message-Id: <199706230946.LAA27628@arthur.u-strasbg.fr>
From: Christian Boos <boos@arthur.u-strasbg.fr>
To: Jerome Vouillon <vouillon@clipper.ens.fr>
Subject: Functors & Classes (was Re: Q: about type inclusion)
In-Reply-To: <Pine.SUN.3.95.970418151930.289A-100000@doris>
<Pine.SUN.3.95.970418151930.289A-100000@doris>
Hello,
I just want to make a few additional comments on this old (18 April)
discussion:
Jerome Vouillon writes:
>
>
> Hello,
>
> C. Boos writes:
> > I was at first puzzled by an error message saying "type x is not
> > included in type y", because type x was a class inherited from class y,
> > until I realized that there is two distinct notions of type inclusion
> > in the langage : module type inclusion and class subtyping.
> > However, I don't see why they couldn't mix, in particular on the
> > example given at the end of this message.
>
> There are two reasons for that. First, the abbreviations must remain
> the same. In your example, type Bimpl.a expands to < a: int; b: int >,
> whereas A.a would expand to < a: int >. Second, the method a (for
> instance) is typed assuming that the type of self is an instance of
> < a: int; b: int; .. >. In particular, method a could invoke method
> b, and expect it to return an int. If your example did succeed, the
> type of self in class A.a would only by constraint to be of the shape
> < a: int; .. >, which is not correct: this is a more general type than
> the previous one, and then nothing prevents you anymore to add a
> method b of type bool in the subclass of A.a.
>
> So, it is not possible to hide public methods a posteriori.
OK, I see. The problem is that this last hypothetical method b : bool
could be called in place of the original method b : int, which will
be dynamically overriden. But C++ distinguishes virtual and non-virtual
methods : if O'Caml does the same thing, would this problem disappear ?
Then it would be possible to mix functors and classes. I think that now
this is a rather difficult task. Given a functor F of type A -> B,
a class A.c specifies a set of methods that needs to be matched EXACTLY
when you implement the c class.
This is too constraining, because when you use different implementations,
you often need different additional methods as well.
Maybe there are other ways than using explicit non-virtual public methods
(use private methods ?) for specifying a base class in a functor,
but with the current language I don't see how.
------------------------------------------------------------------
Bonjour,
J'aimerais juste refaire un commentaire sur cette vieille discussion.
> [voir plus haut]
> So, it is not possible to hide public methods a posteriori.
OK, mais le probleme vient du fait qu'une methode publique peut etre
surchargee dans une sous-classe ? Si comme en C++, les methodes
virtuelles et non-virtuelles etaient distinguees, il serait possible
de "cacher" a posteriori les methodes publiques non-virtuelles ?
Du coup, on pourrait utiliser conjointement les classes et les foncteurs,
parceque j'avoue que jusqu'a maintenant, je me suis casse les dents sur ce
probleme.
En effet, si dans un foncteur de type F: A -> B, on specifie une classe A.c,
dans tous les modules implementant cette classe, on doit utiliser
EXACTEMENT les memes methodes pour c, ni plus ni moins.
C'est trop contraignant pour etre utilisable en pratique, puisque si l'on a
des modules differents, c'est en general qu'on a des implementations
differentes, et donc besoin de methodes additionelles differentes.
Peut-etre y a-t-il d'autres facons de faire, avec des methodes privees par
ex., pour arriver a specifier une classe de base dans un foncteur,
mais en tout etat de cause, avec le langage actuel je ne vois pas.
-- Christian
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:11 MET