Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Markus Mottl <mottl@miss.wu-wien.ac.at>
To: Didier.Remy@inria.fr
Cc: caml-list@inria.fr (OCAML)
Subject: Re: creating fresh objects of type 'self
Date: Mon, 12 Apr 1999 13:03:54 +0100 (MET DST)	[thread overview]
Message-ID: <199904121103.NAA00431@miss.wu-wien.ac.at> (raw)
In-Reply-To: <19990412103328.05240@morgon.inria.fr> from "Didier Remy" at Apr 12, 99 10:33:28 am

> > 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




  reply	other threads:[~1999-04-12 17:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-09 22:56 Markus Mottl
1999-04-12  8:33 ` Didier Remy
1999-04-12 12:03   ` Markus Mottl [this message]
1999-04-12 10:39     ` Didier Remy
1999-04-12 13:10       ` Markus Mottl

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=199904121103.NAA00431@miss.wu-wien.ac.at \
    --to=mottl@miss.wu-wien.ac.at \
    --cc=Didier.Remy@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