From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id UAA04931 for caml-redistribution; Wed, 23 Oct 1996 20:00:12 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.6.10/8.6.6) with ESMTP id PAA27499 for ; Wed, 23 Oct 1996 15:02:11 +0200 Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.7.6/8.7.1) with ESMTP id PAA15429 for ; Wed, 23 Oct 1996 15:02:01 +0200 (MET DST) Received: from orion.kurims.kyoto-u.ac.jp (orion.kurims.kyoto-u.ac.jp [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.7.5/3.4W2) with SMTP id WAA02333 for ; Wed, 23 Oct 1996 22:01:56 +0900 (JST) Received: (from garrigue@localhost) by orion.kurims.kyoto-u.ac.jp (SMI-8.6/3.5Wbeta) id WAA02942; Wed, 23 Oct 1996 22:01:55 +0900 Date: Wed, 23 Oct 1996 22:01:55 +0900 Message-Id: <199610231301.WAA02942@orion.kurims.kyoto-u.ac.jp> From: Jacques GARRIGUE To: caml-list@inria.fr In-reply-to: (message from Jerome Vouillon on Thu, 10 Oct 1996 17:30:05 +0200 (MET DST)) Subject: Re: Constructeurs en O'Caml Sender: weis About problems of initialization of classes, Jerome Vouillon wrote: [..] > The second solution is to change the scoping rules for instance > variables. An instance variable would also be visible to instance > variables appearing next. The class parameters could also be > considered as a private instance variables and be visible in > methods. Instance variables only used during object initialization > (and that does not appears in any method) would be omitted from the > object. Some examples follows: > (* Point (3) *) > class c f = > val x = Unix.time () > inherit a (f x) > end > (* Point (2) *) > let count = ref 0 > class c () = > val _ = incr count > end > (* Class parameter used in a method *) > class c x = > method m = x > end > Pros: - Simpler scoping rules. > - A bit more compact (see third example). > Cons: - Which values appears in or are omitted from the object is not > obvious to the user. > - One must rely on some more or less clever compiler > optimizations, so that instance variables not used in any > method are omitted from the object (as a side-effect, the > implementation is more complex). This looks like a very good idea for me. In particular, the impossibility to use parameters of the class in methods is rather hard to grasp to beginners, and this is solved by this approach. On the other hand, I think the compiler should only omit unused private variables. Then wether the optimization is really done or not can be ignored by the user. If you start omitting public ones, you will have strange cases were the type of the class depends on this optimization. Actually you may want to define non referenced instance variables in a class, just to use them through inheritance (stange, but, why not ?). I also take this occasion to say that I also like another idea proposed on this forum, of changing the associativity of # (message sending). This makes syntax closer to Smalltalk, which seems logical. For the concurrence with O'Labl, or rather LablTk, which was evocated in that message, I was aware of that, but I think this must be restricted to real configuration commands. Creating a class without real objects, just to create a function with optional parameters, is possible, but doesn't seem very clean to me: the call syntax becomes rather complex. And with a not-to-big number of arguments, optionals are more efficient. class search (s : string) as self = val string = s val mutable forward = true val mutable nocase = true method backward = forward <- false; self method exact = nocase <- false; self method go = search s forward nocase end new search "hello" #backward #go ---> search "hello" false true With optionals: let search' s ?:forward [< true >] ?:nocase [< true >] = search s forward nocase search' "hello" forward:false ---> search "hello" false true Still, this is an amusing technique, close to what is used in C. Jacques --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue@kurims.kyoto-u.ac.jp JG