extending a functional updater implicitly publicizes sub-updater method?

extending a functional updater implicitly publicizes sub-updater method?

[Marc Herbert]

[This is a shameless repost of
  http://groups.google.com/groups?selm=d1coe3%242l%241%40wolfberry.srv.cs.cmu.edu
 Looks like comp.lang.ml is more comp.lang.sml than comp.lang.caml...]

I don't understand why my private subupdater is "made public implicitly"

Example inspired from
 http://caml.inria.fr/ocaml/htmlman/manual005.html#ss:functional-objects
This sample code is quite similar to extending the constructor of a
superclass.


class functional_point =
   object
     val x = 0
     method private forward = {< x = x + 1 >}
   end;;

class functional_color_point =
   object
     inherit functional_point as super
     val color = 0

     (* color_forward is made implicitly public ?!? *)
     method private color_forward = {< color = color + 1 >}

     method private forward = super#forward#color_forward
   end;;


Same issue when "forward" method is not private.
I suspect there is some type issue here... could someone explain this?
Thanks in advance.

Re: [Caml-list] extending a functional updater implicitly publicizes sub-updater method?

[Remi Vanicat]

On Tue, 22 Mar 2005 20:18:06 +0100 (CET), Marc Herbert
<marc.herbert.1@ml.free.fr> wrote:
> [This is a shameless repost of
>   http://groups.google.com/groups?selm=d1coe3%242l%241%40wolfberry.srv.cs.cmu.edu
>  Looks like comp.lang.ml is more comp.lang.sml than comp.lang.caml...]

For an unknown reason, my answer (message-id:
<87r7ieuf54.dlv@vanicat.homelinux.org>) that have been post on the
neuf.fr news server does not appear on google, so I will suppose that
it hasn't propagate, and I will re-answer here

> I don't understand why my private subupdater is "made public implicitly"
> 
> Example inspired from
>  http://caml.inria.fr/ocaml/htmlman/manual005.html#ss:functional-objects
> This sample code is quite similar to extending the constructor of a
> superclass.
> 
> class functional_point =
>    object
>      val x = 0
>      method private forward = {< x = x + 1 >}
>    end;;
> 
> class functional_color_point =
>    object
>      inherit functional_point as super
>      val color = 0
> 
>      (* color_forward is made implicitly public ?!? *)
>      method private color_forward = {< color = color + 1 >}
> 
>      method private forward = super#forward#color_forward
>    end;;

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. Then
as a private method can be made public latter, ocaml make the method
public to make the code correct, and give you this warning.

wish for something like 'restricted' methods

[james woodyatt]

On Mar 22, 2005, at 11:56 AM, Remi Vanicat wrote:
>
> 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. Then
> as a private method can be made public latter, ocaml make the method
> public to make the code correct, and give you this warning.

This discussion reminds me of a related issue that has always made me 
wonder if the language couldn't be improved a little.

I'd like to be able to define a method that isn't public, but also 
isn't private.  I don't know what to call this method qualification.  
For the purposes of this discussion *only*, I'll pick a proposed word 
to reserve: restricted.

A "restricted" method would be one that may only be invoked within the 
methods of objects constrained to the type of any classtype-def in 
their classtype-definition.

An example:

	class type ['q] p =
	  object
	    constraint 'q = #q
	    method restricted f: 'q -> unit
	  end
	and q =
	  object
		val p: #q #p
		method g: unit
	  end

In the class type definition above, I want objects of class type q to 
be able to define a method g which delegates to the method f defined in 
class type 'q p, but I don't want the delegate to be visible outside 
methods in objects of type (or subtypes) of 'q p and q (which is 
currently the case).

I would expect that, with inheritance, restricted methods would be 
implicitly inherited, private methods could be explicitly promoted to 
restricted methods, and restricted methods could be explicitly promoted 
to public methods.  I would also expect that restricted methods could 
also be virtual methods.

I can see how restricted methods would have to appear in object types, 
and they would need to be distinguished from public methods 
appropriately, i.e. (< restricted 'p 'q. f: 'q. (#q as 'q) -> unit; .. 
 > as 'p) would describe an object with a method f restricted to methods 
in objects of a limited set of types, listed as 'p and 'q in the type.  
The "restricted 'p 'q." clause would separate the public methods from 
the restricted methods.

It would be especially nice if class type constraints could be used to 
hide a restricted method or explicitly constrain it to be just a 
private method.  That would allow class types in module signatures to 
present restricted methods as private methods outside the module 
structure when the class definitions inside the module structure 
defines the methods as restricted.

Have ideas along these lines been considered or even researched?  I 
realize that there are ways to get along without a feature like this, 
and they're not that bad all things considered.  (Example: use public 
methods with abstract types in the module signature, and delegate 
through them to private methods with concrete types.)  This 
"restricted" method type would just be a convenient way of allowing the 
programmer to express this intent within the language itself.

I suppose I might consider (whenever I get the time and inclination) 
the problem of writing a CamlP4 extension to do something like this, 
but my intuition tells me it would be better if it was handled by the 
compiler itself.

Note: I recognize that this language feature could not be used to solve 
the problem that M. Herbert is raising in the referenced thread.


--
james woodyatt <jhw@wetware.com>

Re: [Caml-list] wish for something like 'restricted' methods

[Jacques Garrigue]

From: james woodyatt <jhw@wetware.com>

> I'd like to be able to define a method that isn't public, but also 
> isn't private.  I don't know what to call this method qualification.  
> For the purposes of this discussion *only*, I'll pick a proposed word 
> to reserve: restricted.
> 
> A "restricted" method would be one that may only be invoked within the 
> methods of objects constrained to the type of any classtype-def in 
> their classtype-definition.

Reading the remainder of your mail, I couldn't understand your notion
of restricted method.
Maybe it would be better if you give an exemple of situation where you
need this new expressiveness, rather than explicitely define a new
notion, as there may be several solutions to your problem.

> Have ideas along these lines been considered or even researched?  I 
> realize that there are ways to get along without a feature like this, 
> and they're not that bad all things considered.  (Example: use public 
> methods with abstract types in the module signature, and delegate 
> through them to private methods with concrete types.)  This 
> "restricted" method type would just be a convenient way of allowing the 
> programmer to express this intent within the language itself.

Jerome Vouillon (the original implementor of the ocaml object system)
wrote a paper about using views to allow arbitrary hiding of methods.

 Combining subsumption and binary methods: An object calculus with views
 In Proceedings of the 28th ACM Conference on Principles of Programming
 Languages, pages 290\u2013303, 2001

This may be related to what you want. However there is no plan to
include views in ocaml.

On the other hand, I have just extended the ocaml type system to allow
the use of private structural types, i.e. abstract types where you
still allow access to some methods.
Then you can write something like this:

module M : sig
  type p = private < m: int; .. >
  type q = private < g: int; .. >
  val new_p : unit -> p
  val new_q : p -> q
end = struct
  class p = object
    method m = 3
    method f (q : q) = q#h
  end
  and q (x : p) = object (self)
    method g = x#f (self :> q)
    method h = 7
  end
  let new_p () = new p
  let new_q = new q
end

where f and h are "friend" methods.

Jacques Garrigue

Re: [Caml-list] wish for something like 'restricted' methods

[james woodyatt]

On Mar 22, 2005, at 9:03 PM, Jacques Garrigue wrote:
>
> Reading the remainder of your mail, I couldn't understand your notion
> of restricted method.

Looking at the literature you referenced, it would appear that I am 
asking for something that better supports "friend" relationships.  My 
notion is not well-formed.  (No surprise: I am not formally trained.)

> Jerome Vouillon (the original implementor of the ocaml object system)
> wrote a paper about using views to allow arbitrary hiding of methods.
>
>  Combining subsumption and binary methods: An object calculus with 
> views
>  In Proceedings of the 28th ACM Conference on Principles of Programming
>  Languages, pages 290\u2013303, 2001
>
> This may be related to what you want. However there is no plan to
> include views in ocaml.

I downloaded this paper from Portal (I am a SIGPLAN member) and studied 
it carefully.  I'm pretty sure I followed the math without getting 
lost.  The paper appears to cover *exactly* the problem that concerns 
me-- for precisely the reasons mentioned in its introductory section.  
My notion of "restricted" methods is a somewhat limited subset of what 
his "views" describe more generally.

[ From the paper referenced above by Jérôme Vouillon... ]
>>
>> Information hiding is of key importance for making programs more 
>> readable, secure and maintainable.  In particular, for abstraction 
>> purposes, one would expect to be able to specify freely what methods 
>> of a class are exported from a package (or a module) to the remainder 
>> of a program.  Furthermore, abstraction should not be impeded by the 
>> need for complex interaction between objects.  For instance, if 
>> objects from two different classes are to interact with one another, 
>> it should still be possible to hide the methods involved in the 
>> interaction.  This means that the objects must be able to communicate 
>> via methods not present in the interfaces exported by the classes to 
>> the rest of the program.  (A class or a function having such a 
>> privileged access to another class is commonly named a *friend*.)

This is what my wish is about.  Naturally, my enthusiasm is crushed by 
the time we reach the concluding paragraph.

[ Continuing from the conclusion of the referenced paper... ]
>>
>> Our calculus does not currently handle multiple inheritance.  We hope 
>> that multiple inheritance is possible even though this might require 
>> a significantly different semantics.  This is another important 
>> direction for future work.

Sigh.  I hope this work is continuing.

> On the other hand, I have just extended the ocaml type system to allow
> the use of private structural types, i.e. abstract types where you
> still allow access to some methods.

These are cool, but they do not satisfy my principle concerns.  The 
"views" thing seems like the best alternative I've seen so far.  Let me 
put more thought into what is my specific wish to see if I can imagine 
how to deal with the multiple inheritance problem.


--
james woodyatt <jhw@wetware.com>

private methods restricted to self?

[Marc Herbert]

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



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

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.


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.

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

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

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


-- 
So einfach wie möglich. Aber nicht einfacher -- Albert Einstein

Re: [Caml-list] private methods restricted to self?

[Jacques Garrigue]

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