From: Jerome Vouillon <vouillon@clipper.ens.fr>
To: Vyskocil Vladimir <Vladimir.Vyskocil@sophia.inria.fr>
Cc: caml-list@inria.fr
Subject: Re: Constructeurs en O'Caml
Date: Thu, 10 Oct 1996 17:30:05 +0200 (MET DST) [thread overview]
Message-ID: <Pine.3.89.9610101156.A7285-0100000@vedette> (raw)
In-Reply-To: <199610091044.MAA16986@psyche.inria.fr>
> Yes, but such contructor can't call a object method because self is
> bind only at execution ie I can't do the following :
>
> class my_class name as self =
> (* MEMBERS *)
>
> val n =
> (* begin constructor *)
> self#init;
> ...;
> (* end constructor *)
> name
>
> (* METHODS *)
> method init =
> ...
> end
At the moment, you have to write a wrapper around class constructor `new
my_class':
let new_my_class name =
let obj = new my_class name in
(* begin constructor *)
self#init;
...;
(* end constructor *)
obj
But you have to do it again for any subclass of my_class.
I had kept object initialisation very simple (only initialization of
instance variables) because I did not know exactly what was needed.
Here are the problems I see at the moment:
(1) One cannot access self during object creation (for instance to
create a double link to another object, or register the object).
(2) Side-effects during creation must occurs during a variable
initialization.
(3) One cannot share any computation (for instance, one could want
the value of two instance variables to depend on the result
of a common computation).
For solving point (1) and (2), I think that a new class component
`initializer expr' should be added (yet another keyword...). These
expressions `expr' would be evaluated after the initialization of
instance variables (object creation would be a two-pass process: first
initialization of instance variables, then evaluation of `initializer'
bodies). This is cleaner than having anonymous instance variables
`val _ = ...' with a special semantics, or a constructor method.
For point (3), I see two possible solutions, but I'm not sure
of which one is the best solution.
The first solution is to add yet another class component
`let x = expr in'. `let'-bound variables would be visible from
instance variable definitions, but not from method definitions. One
could also have a `let _ = expr' as an alternative to `initializer'
component for point (2). Here are a few examples:
(* Point (3) *)
class c f =
let x0 = Unix.time () in
val x = x0
inherit a (f x0)
end
(* Point (2) *)
let count = ref 0
class c =
let _ = incr count
end
Pros: - Variables used during initialization and instance variables
are clearly distinguished.
- Easy to implement (this might not be a good argument)
Cons: - Still more complex scoping rules.
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).
-- Jerome Vouillon
next prev parent reply other threads:[~1996-10-16 6:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-10-09 9:25 Vyskocil Vladimir
1996-10-09 10:26 ` Christian Boos
1996-10-09 10:44 ` Vyskocil Vladimir
1996-10-09 12:12 ` Christian Boos
1996-10-10 15:30 ` Jerome Vouillon [this message]
1996-10-23 13:01 ` Jacques GARRIGUE
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.3.89.9610101156.A7285-0100000@vedette \
--to=vouillon@clipper.ens.fr \
--cc=Vladimir.Vyskocil@sophia.inria.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox