From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <garrigue@math.nagoya-u.ac.jp>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE 
	autolearn=disabled version=3.1.3
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by yquem.inria.fr (Postfix) with ESMTP id AD260BBAF
	for <caml-list@yquem.inria.fr>; Mon,  6 Apr 2009 06:31:13 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAOsh2UmCNhAB/2dsb2JhbADHdIQPBg
X-IronPort-AV: E=Sophos;i="4.39,328,1235948400"; 
   d="scan'208";a="24014410"
Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2009 06:31:12 +0200
Received: from localhost (orion [130.54.16.5])
	by kurims.kurims.kyoto-u.ac.jp (8.13.8/8.13.8) with ESMTP id n364V7XX010613;
	Mon, 6 Apr 2009 13:31:07 +0900 (JST)
Date: Mon, 06 Apr 2009 13:30:54 +0900 (JST)
Message-Id: <20090406.133054.00414260.garrigue@math.nagoya-u.ac.jp>
To: goswin-v-b@web.de
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Bug? Constraints get ignored in methods
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
In-Reply-To: <874ox5jw6o.fsf@frosties.localdomain>
References: <87ab71ic1f.fsf@frosties.localdomain>
	<20090402.173911.68542703.garrigue@math.nagoya-u.ac.jp>
	<874ox5jw6o.fsf@frosties.localdomain>
X-Mailer: Mew version 4.2 on Emacs 22.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam: no; 0.00; bug:01 val:01 mutable:01 caml-list:01 coercion:01 coercion:01 define:02 inheriting:02 garrigue:03 garrigue:03 constraints:03 seems:03 seems:03 jacques:03 jacques:03 

From: Goswin von Brederlow <goswin-v-b@web.de>
> > If you really want to stick to methods only (because of library
> > design, for instance), then a clever trick is to use a coercion
> > methods:
> >
> > class virtual base_type =
> >   object (self)
> >     val mutable virtual next : base_type option
> 
> Why is next virtual here? Doesn't that require that anyone inheriting
> base_type has to define their own version of next? Seems like needless
> duplication.

No real reason. Just that you class type contained such field, so I
pasted it it the least effecting way. But since no method inside
base_type accesses it, I agree that it seems better not to put it
there.

> >     method virtual set_next_base : base_type option -> unit
> >     method as_base = (self :> base_type)
> >     method set_next : 'a. <as_base : base_type; ..> as 'a -> unit =
> >       fun x -> self#set_next_base x#as_base
> >   end

A small typo in the above. Like in the function example it should be

   fun x -> self#set_next_base (Some x#as_base)

> This helps a lot. Nice little trick to go through an immediate object
> type.

Actually, the self coercion and the use of a non-abbreviated object
type are independent, but in general it is too heavy to use the second
without the first.

        Jacques Garrigue