* Q: about type inclusion @ 1997-04-09 10:01 Christian Boos 1997-04-18 13:34 ` Jerome Vouillon 0 siblings, 1 reply; 3+ messages in thread From: Christian Boos @ 1997-04-09 10:01 UTC (permalink / raw) To: caml-list [Summary: it seems that module type inclusion doesn't use the notion of class subtyping. Is there a theoretical reason for that or could it be done in the future ?] Hello, 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. Any comments welcomed ! ------------------------------------------------------------------ [Resume: il semblerait que l'inclusion entre types de modules n'exploite pas les relations de sous-typage entre classes. Y a-t-il une impossibilite quelque part ou bien est-ce realisable ?] Bonjour, Bien que presentant de nombreuses similitudes, l'inclusion entre types de modules et le sous-typage entre classes sont deux choses distinctes dans le langage. Cependant je n'entrevois pas les raisons d'une incompatibilite de fond entre les deux, notamment celle conduisant a produire une erreur sur l'exemple ci-apres. ------------------------------------------------------------------ module type A = sig class a (unit) = method a : int end end module type B = sig class a (unit) = method a : int method b : int end end module Bimpl = struct class a () = method a = 1 method b = 2 end end module B = (Bimpl : B) (* of course *) (* but *) module A = (Bimpl : A) Characters 16-21: Signature mismatch: Modules do not match: sig class a (unit) = method a : int method b : int end end is not included in A Class types do not match: class a (unit) = method a : int method b : int end is not included in class a (unit) = method a : int end # -- Christian ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Q: about type inclusion 1997-04-09 10:01 Q: about type inclusion Christian Boos @ 1997-04-18 13:34 ` Jerome Vouillon 1997-06-23 9:46 ` Functors & Classes (was Re: Q: about type inclusion) Christian Boos 0 siblings, 1 reply; 3+ messages in thread From: Jerome Vouillon @ 1997-04-18 13:34 UTC (permalink / raw) To: Christian Boos; +Cc: caml-list Hello, > 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. -- Jerome > ------------------------------------------------------------------ > > module type A = > sig class a (unit) = method a : int end end > > module type B = > sig class a (unit) = method a : int method b : int end end > > > module Bimpl = > struct class a () = method a = 1 method b = 2 end end > > > module B = (Bimpl : B) (* of course *) > > (* but *) > > module A = (Bimpl : A) > > Characters 16-21: > Signature mismatch: > Modules do not match: > sig class a (unit) = method a : int method b : int end end > is not included in > A > Class types do not match: > class a (unit) = method a : int method b : int end > is not included in > class a (unit) = method a : int end > # ^ permalink raw reply [flat|nested] 3+ messages in thread
* Functors & Classes (was Re: Q: about type inclusion) 1997-04-18 13:34 ` Jerome Vouillon @ 1997-06-23 9:46 ` Christian Boos 0 siblings, 0 replies; 3+ messages in thread From: Christian Boos @ 1997-06-23 9:46 UTC (permalink / raw) To: Jerome Vouillon; +Cc: caml-list 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~1997-06-23 10:23 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-04-09 10:01 Q: about type inclusion Christian Boos 1997-04-18 13:34 ` Jerome Vouillon 1997-06-23 9:46 ` Functors & Classes (was Re: Q: about type inclusion) Christian Boos
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).