Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] classes, objects, and class variables
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-12-23 (07:38)
From: james woodyatt <jhw@w...>
Subject: Re: [Caml-list] classes, objects, and class variables
[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 Archives:
Bug reports: FAQ:
Beginner's list: