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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 43A667E5F for ; Thu, 31 Aug 2006 08:55:25 +0200 (CEST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7V6tN52026558 for ; Thu, 31 Aug 2006 08:55:24 +0200 Received: from localhost (orion [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.13.7/8.13.7) with ESMTP id k7V6tH1s015245; Thu, 31 Aug 2006 15:55:18 +0900 (JST) Date: Thu, 31 Aug 2006 15:55:12 +0900 (JST) Message-Id: <20060831.155512.94497249.garrigue@math.nagoya-u.ac.jp> To: micha-1@fantasymail.de Cc: caml-list@inria.fr Subject: Re: [Caml-list] native values in objects from c From: Jacques Garrigue In-Reply-To: <20060829140717.108000@gmx.net> References: <20060829115002.108020@gmx.net> <20060829.220511.27011347.garrigue@math.nagoya-u.ac.jp> <20060829140717.108000@gmx.net> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44F687DB.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; pointer:01 aargh:01 3.08:01 abstract:01 caml-list:01 behaviour:01 define:01 defined:02 linear:02 variables:02 native:02 external:02 objects:02 garrigue:03 garrigue:03 From: "Michael Wohlwend" > > Well, since fields start at 0, the 3rd field is number 2. > > thanks for helping; actually my fault was to think the elements are linear ordered, even if the class is inherited (I want to get the first value of the base). The values are ordered reverse of definition, whereas the docu says: > "Instance variables are stored in the order in which they appear in the class definition" > > In the end I want to hide public methods which give you access the the pointer to the c++ object and hiding an external method is easy. 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. Note also that it is pretty easy to define another object, with the same type as the one you want to interface with C++, but with completely different fields. I.e., accessing object fields from the C side is always dangerous. A better approach it to add a method which returns the field with an abstract type, this way users cannot break the type system. Jacques Garrigue