Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Protected methods
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Alessandro Baretta <alex@b...>
Subject: Re: [Caml-list] Protected methods

Jacques Garrigue wrote:
>>>You cannot call m from other modules because you cannot create values
>>>for the type "protector".
>>Effective, definitely, but practical? Is this not supposed 
>>to be a feature of any general purpose object oriented language?
> Actually, this seems perfectly practical.
> If you have some good reason to "protect" a method, you can do it
> cleanly.

I would not call adding a fake type a clean solution. It's 
not idiomatic. A "protected" keyword is cleaner and easier 
to handle. Although it might be very tricky to implement in 
a language with type inference.

> By the way, ocaml is not a general purpose object-oriented languages,
> but a general purpose functional language with object-oriented
> features. In particular, encapsulation is supported by the module
> system rather than the class system.
> Even in object-oriented languages, I've seen heated discussions on
> whether using friend classes was good style or not.

This is too big an issue for me. I only expressed the need I 
perceive for a construct to enable different instances of 
the same class to call methods on their siblings which are 
not visible to the general public. What I really want is a 
way to restrict through a type coercion the type of my 
"autofriendly" class.

>>Anyway, for the meantime I'll keep the method public, and 
>>make sure I don't use it anywhere except where it makes 
>>sense, and I'll wait for some more insight from the developers.
> Note that in many cases there are other ways to obtain the expected
> behaviour.

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)
   let make_public () -> (new protected :> public)

If this a working alternative, I would prefer over both the 
protector type and the protected keyword: clean, simple, and 

> For instance, if only one specific object is supposed to use a method,
> you might register a private callback with it rather than the other
> way round.
> Jacques Garrigue

Hrmmm.... uuuhhh.... yes? What's it mean?

Thank you very much, Jacques, for taking time to answer my 
former post.


To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: