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>