From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA02616; Tue, 25 Jun 2002 23:35:20 +0200 (MET DST)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA02622 for <caml-list@pauillac.inria.fr>; Tue, 25 Jun 2002 23:35:14 +0200 (MET DST)
Received: from bastion.artisan.com (bastion.artisan.com [209.144.161.130])
	by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g5PLZCr04964
	for <caml-list@inria.fr>; Tue, 25 Jun 2002 23:35:12 +0200 (MET DST)
Received: from ypmaster.artisan.com (ypmaster [172.16.2.1])
	by bastion.artisan.com (8.9.2/8.9.2) with ESMTP id OAA16933;
	Tue, 25 Jun 2002 14:34:10 -0700 (PDT)
Received: from granite.artisan.com (granite [172.16.10.97])
	by ypmaster.artisan.com (8.9.2/8.9.2-arti) with ESMTP id OAA22780;
	Tue, 25 Jun 2002 14:33:42 -0700 (PDT)
Received: (from bpr@localhost)
	by granite.artisan.com (8.9.2/8.9.2) id OAA07799;
	Tue, 25 Jun 2002 14:33:41 -0700 (PDT)
X-Authentication-Warning: granite.artisan.com: bpr set sender to bpr@artisan.com using -f
From: Brian Rogoff <bpr@artisan.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15640.57781.702368.271986@granite.artisan.com>
Date: Tue, 25 Jun 2002 14:33:41 -0700
To: erayo@cs.bilkent.edu.tr
Cc: garrigue@kurims.kyoto-u.ac.jp, jhw@wetware.com, caml-list@inria.fr
Subject: Re: [Caml-list] subtyping and inheritance (bug?)
References: <BB7FA3E8-87E5-11D6-BC7A-000502DB38F5@wetware.com>
	<20020625115430E.garrigue@kurims.kyoto-u.ac.jp>
	<200206251522.28391.erayo@cs.bilkent.edu.tr>
X-Mailer: VM 7.00 under Emacs 20.7.1
Sender: owner-caml-list@pauillac.inria.fr
Precedence: bulk

Eray Ozkural writes:
> On Tuesday 25 June 2002 05:54, Jacques Garrigue wrote:
> > Sure. The children_set method contains a contravariant occurence of 'self.
> > It cannot be compatible with its subclasses.  You don't need to have
> > mutable data to have variance incompatibilities.
> > No bug, business as usual.
> 
> Which programming style would express the intended semantics, then? I guess we 
> would need a slightly different formulation.

Yes, you need a different formulation. If you want to have a tree class but
want to create a family of color_trees which can be coerced to each other
and put on the same list, something like this 

class ['a] tree =
  object 
    val v = (None : string option)
    val ch = ([] : 'a list)
    method value_get = v
    method value_set x = {< v = x >}
    method children_get = ch
    method children_set x = {< ch = x >}
  end;;

class color_tree =
  object
    inherit [color_tree] tree
    method color = "green"
  end;;

class pine_tree =
  object
    val mutable age = 0.0
    inherit color_tree
    method color = "evergreen"
    method age = age
  end;;

class fake_tree =
  object
    inherit color_tree
    method color = "olivegreen"
    method material = "fantastic plastic"
  end;;

now these can all be coreced to color_tree, and they have a colortree list 
type on method children_get. 

let colortree = new color_tree;;
let pinetree = new pine_tree;;
let faketree = new fake_tree;;

let trees = [colortree; 
	     (pinetree :> color_tree);
	     (faketree :> color_tree)];;

faketree#children_set trees;;

If you create a new class, 

class palm_tree =
  object
    inherit [palm_tree] tree
    method color = "palmgreen"
    method fronds = true
  end;;

then you won't be able to do the coercion. 

let palmtree = new palm_tree;;
(palmtree :> color_tree);; (* ERROR! *)

-- Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners