caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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






  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;
as well as URLs for NNTP newsgroup(s).