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