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 JAA14712; Sat, 20 Jul 2002 09:34:16 +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 JAA14703 for ; Sat, 20 Jul 2002 09:34:15 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from athlon.baretta.com (r-mi214-6a94.tin.it [62.211.4.94]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g6K7YEj07620 for ; Sat, 20 Jul 2002 09:34:14 +0200 (MET DST) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id 54142273C4; Sat, 20 Jul 2002 09:41:32 +0200 (CEST) Message-ID: <3D39142C.4000404@baretta.com> Date: Sat, 20 Jul 2002 09:41:32 +0200 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: it, en MIME-Version: 1.0 To: Jacques Garrigue , Ocaml Subject: Re: [Caml-list] Protected methods References: <3D36AA1B.2090101@baretta.com> <20020719175002N.garrigue@kurims.kyoto-u.ac.jp> <3D37E364.5060607@baretta.com> <20000720094622J.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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 end >> val make_public : unit -> public >>end = struct >> class type public = object end >> class protectd = >> object (self : #public) >> >> >> 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