caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: david.baelde@ens-lyon.org
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] OO design
Date: Mon, 08 May 2006 12:17:43 +0900 (JST)	[thread overview]
Message-ID: <20060508.121743.65190532.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <53c655920605050235k64e70333je8df813239ea3c53@mail.gmail.com>

From: "David Baelde" <david.baelde@gmail.com>

> I'm no OO guru, so my question may be irrelevant, or there just might
> not be an answer, which wouldn't hurt..
> 
> Let's say that I have a base class, with some kind of activation
> procedure: anybody wanting to use the class must call #enter before,
> and then call #leave for releasing. Internally, the methods #do_enter
> and #do_leave are called respectively at the first #enter and last
> #leave.
> 
> Nobody should call the #do_* directly, and I'd also like to make sure
> the #enter and #leave are never overriden, since their behaviour is
> important and actually much more complex than what I said.
> 
> I could just rely on the user who derives my base class, but let's see
> what we can do. First the #do_* should be made private, so they can be
> defined in the derived classes, but never called from the outside. To
> avoid the overriding of #enter and #leave the only solution seems to
> make them normal functions instead of methods. But then how could
> #enter call #do_enter ? I tried to first define the class with public
> #enter and make that method private in the interface, but OCaml told
> me that was impossible.

I would be tempted to say: there is no answer.
Ocaml objects are not about enforcing protocols, but about allowing
inheritance and structural subtyping, and this does not fit well with
your problem.
There are many things you can try to make it harder to derive incorrect
classes, but basically if the user wants to do it, he can.

Yet, since it seems that you are already relying on the (library)
programmer to write correct code for the #do_* methods, another point
of view might be that you just want to make sure that only the final user
of objects cannot break things. Then the technique described in other
answers make sense, for instance prohibiting inheritance from an
already completed class.
An even stronger protection is to make object types private. This way you
are sure than nobody can forge an object of the same type, and you can
even hide public methods if you wish. But you loose inheritance.
See the object example in my paper on private rows about how to do this.

Combining structural subtyping and modular privacy would introduce a
lot extra complexity in the type system.

Jacques Garrigue


  parent reply	other threads:[~2006-05-08  3:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05  9:35 David Baelde
2006-05-05 10:47 ` [Caml-list] " Gerd Stolpmann
2006-05-05 13:00 ` Remi Vanicat
2006-05-05 19:32   ` Andrej Bauer
2006-05-08  3:17 ` Jacques Garrigue [this message]
2006-05-08 21:29   ` David Teller
2006-05-08 21:36     ` Dan Grossman
2006-05-10  2:41       ` Geoffrey Alan Washburn
2006-05-10 16:17         ` [Caml-list] " Dan Grossman
2006-05-10 18:15           ` Geoffrey Alan Washburn
2006-05-10 18:44             ` [Caml-list] " Dan Grossman
2006-05-10 18:35           ` Shawn
2006-05-10 18:47             ` Till Varoquaux
2006-05-10 19:01               ` Shawn
2006-05-10 18:43           ` brogoff
2006-05-11  0:08             ` Geoffrey Alan Washburn
2006-05-11  5:45               ` [Caml-list] " Till Varoquaux
2006-05-11  6:21               ` Jacques Garrigue
2006-05-11 15:48                 ` Geoffrey Alan Washburn
2006-05-08 22:59 [Caml-list] " yoann padioleau

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=20060508.121743.65190532.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=david.baelde@ens-lyon.org \
    /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).