From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id D537E1F4A0 for ; Thu, 31 Aug 2006 10:23:07 +0200 (CEST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by concorde.inria.fr (8.13.6/8.13.6) with SMTP id k7V8N7mg021283 for ; Thu, 31 Aug 2006 10:23:07 +0200 Received: (qmail 16007 invoked by uid 0); 31 Aug 2006 08:22:56 -0000 Received: from 194.25.187.120 by www103.gmx.net with HTTP; Thu, 31 Aug 2006 10:22:56 +0200 (CEST) Cc: caml-list@inria.fr Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 31 Aug 2006 10:22:56 +0200 From: "Michael Wohlwend" In-Reply-To: <20060831.155512.94497249.garrigue@math.nagoya-u.ac.jp> Message-ID: <20060831082256.165610@gmx.net> MIME-Version: 1.0 References: <20060829115002.108020@gmx.net> <20060829.220511.27011347.garrigue@math.nagoya-u.ac.jp> <20060829140717.108000@gmx.net> <20060831.155512.94497249.garrigue@math.nagoya-u.ac.jp> Subject: Re: [Caml-list] native values in objects from c To: Jacques Garrigue X-Authenticated: #20477425 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 44F69C6B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; aargh:01 3.08:01 2006:98 ihrer:98 isdn:98 abstract:01 caml-list:01 caml-list:01 behaviour:01 70%:98 defined:02 native:02 native:02 objects:02 objects:02 -------- Original-Nachricht -------- Datum: Thu, 31 Aug 2006 15:55:12 +0900 (JST) Von: Jacques Garrigue An: micha-1@fantasymail.de Betreff: Re: [Caml-list] native values in objects from c > Aargh, you're right. The behaviour changed between 3.08 and 3.09. > In 3.08, fields are still ordered in definition order, including > inherited ones, but in 3.09, due to an optimization, inherited fields > appear after newly defined ones. The trouble is that this being due > to an optimization, this may change again, so it is not a good idea to > depend on it. o.k., accessing the field from c allready seemed hacky to me :-) > A better approach it to add a method which returns the field with an > abstract type, this way users cannot break the type system. o.k., seems indeed the safer way. thanks, Michael -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer