Re: [Caml-list] Protected methods

[Alessandro Baretta <alex@baretta.com>]

Jacques Garrigue wrote:
> 
> Actually, this is just an alternative model for protection:
> give all your clients the key, and don't give it to other people.
> This makes sense. The key can be a dummy only because the type system
> guarantees that you cannot forge its type.
> The problem with a "protected" keyword is that it should be given a
> semantics. Since an object type is structural (does not belong to a
> specific module), this is unclear how you can define where a protected
> method should be accessible.

I would be happy enough if protected methods were accessible 
to other instances of the same class. This would be easy to 
implement in O'Caml's type system, because the only place 
where protected methods are visible is between the "object" 
and "end" keywords. Nowhere else would the type system need 
to account for the presence of protected keywords.

class a = object private method m = let x = new a in x # m end

> In practice, I probably won't do it that way, but this would require a
> deeper knowledge of your problem.
> For instance, if you want to show an internal state to a limited
> number of clients, you can just have a method returning this state
> with an abstract type. That's certainly more natural.

I fully agree. But what do you do when an instance of class 
a holds other instances of class a which must collaborate 
with the first in order to achieve the functionality of the 
first? One possibility would be have define two classes: a 
front-end, with only the methods which should be generally 
available, and a backend, inheriting from the first and 
adding those methods that are only meaningful for the 
front-end. Otherwise, you define only one class and add a 
protected keyword for these latter methods.

>>How about the following pseudocode? Is it sensible/viable?
>>
>>let module M : sig
>>   class type public = object <public_methods> end
>>   val make_public : unit -> public
>>end = struct
>>   class type public = object <public_methods> end
>>   class protectd =
>>     object (self : #public)
>>     <public_methods>
>>     <protected_methods>
>>   end
>>   let make_public () -> (new protected :> public)
>>end
>>
>>If this a working alternative, I would prefer over both the 
>>protector type and the protected keyword: clean, simple, and 
>>idiomatic.
> 
> 
> This is both sensible and viable.
> The only weakness is that you won't be able to inherit from the public
> version of your class, since it is not a class but only a type.
> If you need to inherit, you should also export the protected version,
> and make sure that all your constructors apply a similar coercion to
> hide protected methods.

This is really all I need. At present, I do not perceive any 
problem with inheritance, but then again, I might in the 
future. At any rate, this is how I plan to modify the code I 
am presently working on, so as to guarantee that the methods 
I do not wish my object to export be kept private.

> This inheritance problem is the only reason I didn't suggest this
> approach first, but it is certainly simpler.
> 
> Jacques Garrigue

Thank you very much for you interesting comments. I hope 
that discussing such issues as this on the list might help 
the Caml team improve its compiler and language.

Alex Baretta

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners