Re: Constructeurs en O'Caml

Jacques GARRIGUE (garrigue@kurims.kyoto-u.ac.jp)
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 <garrigue@kurims.kyoto-u.ac.jp>
To: caml-list@inria.fr
Subject: Re: Constructeurs en O'Caml

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
<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>