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 IAA30136; Tue, 23 Dec 2003 08:38:12 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 IAA30478 for ; Tue, 23 Dec 2003 08:38:11 +0100 (MET) Received: from wetware.com (wetware.wetware.com [199.108.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hBN7cAv21365 for ; Tue, 23 Dec 2003 08:38:10 +0100 (MET) Received: from [208.177.152.18] (helo=[10.0.1.5]) by wetware.com with esmtp (Exim 4.20) id 1AYh71-0003xz-2p; Mon, 22 Dec 2003 23:37:51 -0800 In-Reply-To: <20031120220714O.garrigue@kurims.kyoto-u.ac.jp> References: <20031120220714O.garrigue@kurims.kyoto-u.ac.jp> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: caml-list@inria.fr From: james woodyatt Subject: Re: [Caml-list] classes, objects, and class variables Date: Mon, 22 Dec 2003 23:37:48 -0800 To: Jacques Garrigue X-Mailer: Apple Mail (2.609) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; woodyatt:01 jhw:01 wetware:01 caml-list:01 jacques:01 dynamically:01 monads:01 woodyatt:01 jhw:01 wetware:01 semantics:01 semantics:01 caml:01 garrigue:01 behaviour:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [just now catching up with my caml mail; i left it accumulating unread for a couple months] On 20 Nov 2003, at 05:07, Jacques Garrigue wrote: > > But in this process, I came along with the rather strange behaviour of > class variables. Class variables are defined by a let before any > parameters, for instance > class c = let a = init () in fun ... -> object ... end > Their current semantics is to be evaluated repeatedly, once for c, > but again for all classes inheriting from c. The problem is that this > is costly for the implementation, doesn't fit well with the > possibility to create dynamically an arbitrary number of classes > inheriting from, and that I don't see what it's intended for. > > So I'm planning to revert to the more intuitive semantics: evaluation > when creating c, but never again. > > Does that bother anybody? The behavior you want to change is a behavior I noticed and it bothered me when I noticed it. I just chalked it up to yet another weird thing about classes. In order to get the behavior I wanted, I just lifted all my class variables out of the class definitions and used module signatures to hide them. You want to make this change? I'm supportive. Please do. One request I would make: please retain the functional object semantics and the {< ... >} syntax. I used that feature with state monads and I like it a lot. -- j h woodyatt ------------------- 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