From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id CAA11763; Sat, 20 Jul 2002 02:46:55 +0200 (MET DST)
X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA11753 for <caml-list@pauillac.inria.fr>; Sat, 20 Jul 2002 02:46:54 +0200 (MET DST)
Received: from favie.faith.gr.jp (favie.faith.gr.jp [61.127.175.250])
	by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g6K0kpj04312
	for <caml-list@inria.fr>; Sat, 20 Jul 2002 02:46:52 +0200 (MET DST)
Received: from localhost (dhcp7.faith.gr.jp [192.168.1.17])
	by favie.faith.gr.jp (8.9.3/8.9.3) with ESMTP id JAA22763;
	Sat, 20 Jul 2002 09:46:23 +0900
To: alex@baretta.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Protected methods
In-Reply-To: <3D37E364.5060607@baretta.com>
References: <3D36AA1B.2090101@baretta.com>
	<20020719175002N.garrigue@kurims.kyoto-u.ac.jp>
	<3D37E364.5060607@baretta.com>
X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000720094622J.garrigue@kurims.kyoto-u.ac.jp>
Date: Thu, 20 Jul 2000 09:46:22 +0900
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
X-Dispatcher: imput version 20000228(IM140)
Sender: owner-caml-list@pauillac.inria.fr
Precedence: bulk

From: Alessandro Baretta <alex@baretta.com>
> > 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.

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.

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.

> 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 inheritance problem is the only reason I didn't suggest this
approach first, but it is certainly simpler.

Jacques Garrigue
-------------------
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