caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Jeff Meister <nanaki@gmail.com>
Cc: david.baelde@ens-lyon.org, Chris Yocum <cyocum@gmail.com>,
	caml-list@inria.fr
Subject: Re: [Caml-list] Ocaml and the Fragile Base Class Problem
Date: Sun, 28 Aug 2011 01:08:09 +0200	[thread overview]
Message-ID: <1314486489.3496.179.camel@thinkpad> (raw)
In-Reply-To: <CAHaHOqRCOqWzyPcnQpGH=LUNiMkJsSwcExqALZv5yVwuGMU36g@mail.gmail.com>

Am Samstag, den 27.08.2011, 13:21 -0700 schrieb Jeff Meister:
> I don't understand this part. You can easily hide a public method of
> an object by coercing it to an object type which does not have that
> method.

Right, but in OO design you build a datastructure often from several
types of objects that communicate closely with each other, and should be
considered as a unit ("friends"). Once you make a method public,
however, it is hard to restrict the access to a friend only.

>  Modules also provide excellent information hiding: if you
> don't want anyone else calling your method, make at least one of its
> input types abstract in the interface, and don't provide any values of
> that type.

I used this technique in Http_client (part of Ocamlnet). It works but
feels very strange. It's like retrofitting nominal typing into the
structural OO type system. Once you use it, you give up the possibility
that the user creates a totally independent object definition on its
own. The price is quite high, and one also wonders whether objects are
then still useful, or whether a "normal" module with an abstract type
would do better.

Also, this particular method of information hiding is a feature of the
modules, not of the objects. As such, objects can only hide the inner
state of a single object, which is quite limited.

Let me point out one final thing. Information hiding is simply not a
core concept of OO - which is in the first place a specific way of
structuring the program (e.g. group data and algorithms together), with
an integrated method of adapting object types (subtyping), and giving
control of parts of your algorithm to the user of your class. This
flexibility and openness is in some contradiction to encapsulation and
access control. This is what I meant with "mindset" - the typical OCaml
programmer likes more the latter (I guess).

Gerd

> On Sat, Aug 27, 2011 at 12:37 PM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> > I guess the biggest problem is that structural
> > typing does not offer much for getting information hiding - once a
> > method is public, it is fully public. This is, in some sense, against
> > the mindset of the typical OCaml programmer.
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.
------------------------------------------------------------


  reply	other threads:[~2011-08-27 23:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-27 10:53 Chris Yocum
2011-08-27 11:24 ` Jacques Garrigue
2011-08-27 15:06 ` Gerd Stolpmann
2011-08-27 16:59   ` David Baelde
2011-08-27 19:37     ` Gerd Stolpmann
2011-08-27 20:21       ` Jeff Meister
2011-08-27 23:08         ` Gerd Stolpmann [this message]
2011-08-28  9:31           ` Andreas Rossberg
2011-08-28 10:04             ` Guillaume Yziquel
2011-08-28 10:11             ` Gerd Stolpmann
2011-08-28 10:50               ` Andreas Rossberg
2011-08-29  3:35           ` Jacques Garrigue
2011-08-29 11:19             ` Chris Yocum
2011-08-29 11:47               ` Guillaume Yziquel
2011-08-29 12:03                 ` Chris Yocum
2011-08-31 21:33             ` Alain Frisch
2011-08-31 23:39               ` Jacques Garrigue
2011-08-28 17:58       ` Julien Signoles

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=1314486489.3496.179.camel@thinkpad \
    --to=info@gerd-stolpmann.de \
    --cc=caml-list@inria.fr \
    --cc=cyocum@gmail.com \
    --cc=david.baelde@ens-lyon.org \
    --cc=nanaki@gmail.com \
    /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).