caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: marc.herbert.1@ml.free.fr
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] private methods restricted to self?
Date: Thu, 31 Mar 2005 11:30:05 +0900 (JST)	[thread overview]
Message-ID: <20050331.113005.122575726.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <Pine.LNX.4.58.0503231720090.7887@fcat>

From: Marc Herbert <marc.herbert.1@ml.free.fr>
> On Tue, 22 Mar 2005, Remi Vanicat wrote:
> 
> > > I don't understand why my private subupdater is "made public implicitly"
> 
> > In ocaml, you can only call a private method on self. super#forward
> > is not self, so you cannot call the color_forward method on it.
> 
> Indeed! This other example, without any subclass, is even more
> surprising:
> 
>  class functional_point =
>    object(self)
>      val x = 0
>      val y = 0
>      method private bump_x = {< x = x + 1 >}
>      method private bump_y = {< y = y + 1 >}
> 
>      method private bump_both = self#bump_x#bump_y
>    end
> 
>  Warning: the following private methods were made public implicitly:
>    bump_y

Exactly the same thing: self#bump_x returns a modified copy of self,
so you cannot call private methods on it from outside.
This would break object encapsulation.
This is exactly for this reason that the functional object update
allows to modify several fields simultaneously.

One must distinguish between
1) self (the same object)
2) object of the same class (obtained via update for instance)
3) object sharing a common supertype (including object of self type)
Only (1) allows private method calls.
(2) technically could, but the typing cannot properly detect this
situation, and this would break object encapsulation anyway.
(3) may be from a completely unrelated class, so there is no way to
know its private methods.

> Thanks a lot for the reasoning. But I still don't get the rationale.
> Could I find the answer in Jerôme Vouillon's "an object calculus with
> views"? Elsewhere? Thanks in advance.

Not there, since views are not implemented in ocaml.
And the original paper on object ML does not deal with private
methods, IIRC.
So your only source is the reference manual I suppose.

> About the reference documentation
> ---------------------------------
> 
> However ignorant are my questions above, I nevertheless think the
> documentation is not clear about this whole issue.
> 
> To find this self#private restriction you have to dive into section
> '6.9.2 Class expressions'. Unfortunately you may never go so far since
> the more user-friendly '3.6 Private methods' section gives the less
> restrive, more usual definition:
> 
>   "Private methods are methods that do not appear in object
>   interfaces. They can only be invoked from other methods of the same
>   object."
> 
> which made me think I knew enough about 'private' and prevented me to
> look further.

This sentence describes exactly the behaviour of private methods, and
you don't need to go further.
You should look carefully at: from other methods of the _same_ object.
We are talking here of objects, not of classes. As soon as you are
trying to access another object (even if it is of the same class) you
cannot call private methods.

> Section '6.9.1 class types' also states:
> 
>   "The flag private indicates whether the method can be accessed from
>   outside the class."
> 
> Coming from another OO-language, it's hard to understand "outside" as
> "restricted to self".

This statement is indeed a bit confusing. This should be "from outside the
object". To make it complete, I would write

  "The flag private indicates whether the method can be accessed from
  outside the object (i.e. whether it appears or not in the object
  type.)"

> So as a conclusion I find the manual at least confusing on this, if
> not erroneous. Is it?

It is mostly correct. The main problem is that ocaml's notion of
privacy is very different from Java's, so that people have
preconceptions. From the point of view of encapsulation, the ocaml
approach is more natural, don't you think so?

> By the way, maybe some extra comment in the Warning message above
> would not hurt either.

There are various ways to make a private method public, and they are
not all easy to detect individually, so there is little more that can
be said in general. I'll look into it.

Jacques Garrigue


      reply	other threads:[~2005-03-31  2:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-22 19:18 extending a functional updater implicitly publicizes sub-updater method? Marc Herbert
2005-03-22 19:56 ` [Caml-list] " Remi Vanicat
2005-03-22 23:34   ` wish for something like 'restricted' methods james woodyatt
2005-03-23  5:03     ` [Caml-list] " Jacques Garrigue
2005-03-23  8:22       ` james woodyatt
2005-03-30 13:16   ` private methods restricted to self? Marc Herbert
2005-03-31  2:30     ` Jacques Garrigue [this message]

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=20050331.113005.122575726.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@yquem.inria.fr \
    --cc=marc.herbert.1@ml.free.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).