From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 7D899BC84 for ; Wed, 23 Mar 2005 00:34:53 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j2MNYrvv013536 for ; Wed, 23 Mar 2005 00:34:53 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA11879 for ; Wed, 23 Mar 2005 00:34:52 +0100 (MET) Received: from wetware.wetware.com (wetware.wetware.com [209.218.58.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j2MNYpbS013528 for ; Wed, 23 Mar 2005 00:34:52 +0100 Received: from [69.12.155.90] (helo=[10.0.1.10]) by wetware.wetware.com with esmtp (Exim 4.43) id 1DDstZ-0001E6-5L for caml-list@inria.fr; Tue, 22 Mar 2005 15:34:47 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <6b8a91420503221156e994d7c@mail.gmail.com> References: <6b8a91420503221156e994d7c@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1b4c73f40a9fe87d2bcf34c14afa1e74@wetware.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: wish for something like 'restricted' methods Date: Tue, 22 Mar 2005 15:34:44 -0800 To: The Caml Trade X-Mailer: Apple Mail (2.619.2) X-Miltered: at concorde with ID 4240AB9D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4240AB9B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; woodyatt:01 jhw:01 wetware:01 ocaml:01 ocaml:01 val:01 subtypes:01 implicitly:01 defines:01 compiler:01 referenced:01 woodyatt:01 jhw:01 wetware:01 researched:98 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: 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