From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA28855 for caml-redistribution; Fri, 18 Apr 1997 21:12:29 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA23298 for ; Fri, 18 Apr 1997 15:35:11 +0200 (MET DST) Received: from nef.ens.fr (nef.ens.fr [129.199.96.12]) by nez-perce.inria.fr (8.7.6/8.7.3) with ESMTP id PAA07010 for ; Fri, 18 Apr 1997 15:35:08 +0200 (MET DST) Received: from vedette.ens.fr (vedette.ens.fr [129.199.130.1]) by nef.ens.fr (8.8.5/jtpda-5.1) with ESMTP id PAA14082 ; Fri, 18 Apr 1997 15:35:02 +0200 (MET DST) Received: from doris.ens.fr (doris [129.199.130.4]) by vedette.ens.fr (8.8.5/jb-1.1) id PAA14654 ; Fri, 18 Apr 1997 15:35:02 +0200 (MET DST) Received: from localhost (vouillon@localhost) by doris.ens.fr (8.8.5/jb-1.1) id PAA00296 ; Fri, 18 Apr 1997 15:35:01 +0200 (MET DST) X-Authentication-Warning: doris.ens.fr: vouillon owned process doing -bs Date: Fri, 18 Apr 1997 15:34:58 +0200 (MET DST) From: Jerome Vouillon X-Sender: vouillon@doris Reply-To: Jerome Vouillon To: Christian Boos cc: caml-list@inria.fr Subject: Re: Q: about type inclusion In-Reply-To: <199704091001.MAA28159@arthur.u-strasbg.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: weis 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 > #