[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 <jhw@wetware.com>

-------------------
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