From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA01274 for caml-redistribution; Mon, 12 Apr 1999 19:32:26 +0200 (MET DST)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA01476 for <caml-list@pauillac.inria.fr>; Mon, 12 Apr 1999 13:03:58 +0200 (MET DST)
Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id NAA17395;
	Mon, 12 Apr 1999 13:03:56 +0200 (MET DST)
Received: (from mottl@localhost)
	by miss.wu-wien.ac.at (8.9.0/8.9.0) id NAA00431;
	Mon, 12 Apr 1999 13:03:55 +0200 (MET DST)
From: Markus Mottl <mottl@miss.wu-wien.ac.at>
Message-Id: <199904121103.NAA00431@miss.wu-wien.ac.at>
Subject: Re: creating fresh objects of type 'self
To: Didier.Remy@inria.fr
Date: Mon, 12 Apr 1999 13:03:54 +0100 (MET DST)
Cc: caml-list@inria.fr (OCAML)
In-Reply-To: <19990412103328.05240@morgon.inria.fr> from "Didier Remy" at Apr 12, 99 10:33:28 am
X-Mailer: ELM [version 2.4 PL21]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: weis

> > But I wonder, how I can do something similar to get a "fresh" object.
> 
> The method clone already gives you a fresh copy of the original object.  So
> why aren't you happy with the method clone?

My initial idea was the following:

A parent object that has a list of child objects of the same type and
a method that adds a "fresh" (not a copy!) of the initial object (= as
the parent was created) to this list.

This following example does not work, of course, because "parent" is
not necessarily of type "'self".

  class parent = object (self : 'self)
    val mutable children : 'self list = []
    method add_fresh_object = children <- new parent :: children
  end

This works, of course:

  class parent = object (self : 'self)
    val mutable children : 'self list = []
    method add_fresh_object = children <- {<>} :: children
  end

But this is not the intended result: now we have added a *copy* of
the current object, not of its "fresh" state, i.e. the state it was in
immediately after creation.

At first I thought this could be solved with something like "new 'self",
but didn't think about the problem of what to do with objects that are
created with parameters: the existence of a function like "new 'self"
would then require that a reference to the parameters is kept for every
object so that it can be "freshly" created at anytime.
But the meaning of "new 'self" could be ambiguous if the parameters can
be changed with side-effects. Making copies of the initial parameters
to circumvent this problem is probably also not a good idea - this could
take up tons of memory.
Thus, I fear that a feature like "new 'self" is not one you might want
to add...


I have "solved" my problem now by using a closed object type for the
elements of the list "children". If I want to add an object, which is
of another type (maybe it's further down the inheritance hierarchie),
I just coerce (if possible) the object in question to this closed object
type. This solution is, unfortunately, not so flexible and elegant.

I hope my new problem description is a bit clearer than my last one...

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl