From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 17A12BC48 for ; Wed, 23 Mar 2005 09:22:31 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2N8MUw0011157 for ; Wed, 23 Mar 2005 09:22:30 +0100 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 JAA24208 for ; Wed, 23 Mar 2005 09:22:29 +0100 (MET) Received: from wetware.wetware.com (wetware.wetware.com [209.218.58.1]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2N8MShQ011154 for ; Wed, 23 Mar 2005 09:22:29 +0100 Received: from [69.12.155.90] (helo=[10.0.1.6]) by wetware.wetware.com with esmtp (Exim 4.43) id 1DE18F-0003zs-LJ; Wed, 23 Mar 2005 00:22:27 -0800 In-Reply-To: <20050323.140312.78769966.garrigue@math.nagoya-u.ac.jp> References: <6b8a91420503221156e994d7c@mail.gmail.com> <1b4c73f40a9fe87d2bcf34c14afa1e74@wetware.com> <20050323.140312.78769966.garrigue@math.nagoya-u.ac.jp> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Jacques Garrigue From: james woodyatt Subject: Re: [Caml-list] wish for something like 'restricted' methods Date: Wed, 23 Mar 2005 00:22:23 -0800 To: The Caml Trade X-Mailer: Apple Mail (2.619.2) X-Miltered: at nez-perce with ID 42412746.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42412744.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; woodyatt:01 jhw:01 wetware:01 caml-list:01 referenced:01 well-formed:01 jerome:01 ocaml:01 binary:01 ocaml:01 sigplan:01 subset:01 referenced:01 jerome:01 abstraction:01 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 9:03 PM, Jacques Garrigue wrote: > > Reading the remainder of your mail, I couldn't understand your notion > of restricted method. Looking at the literature you referenced, it would appear that I am=20 asking for something that better supports "friend" relationships. My=20 notion is not well-formed. (No surprise: I am not formally trained.) > Jerome Vouillon (the original implementor of the ocaml object system) > wrote a paper about using views to allow arbitrary hiding of methods. > > Combining subsumption and binary methods: An object calculus with=20 > views > In Proceedings of the 28th ACM Conference on Principles of = Programming > Languages, pages 290\u2013303, 2001 > > This may be related to what you want. However there is no plan to > include views in ocaml. I downloaded this paper from Portal (I am a SIGPLAN member) and studied=20= it carefully. I'm pretty sure I followed the math without getting=20 lost. The paper appears to cover *exactly* the problem that concerns=20 me-- for precisely the reasons mentioned in its introductory section. =20= My notion of "restricted" methods is a somewhat limited subset of what=20= his "views" describe more generally. [ =46rom the paper referenced above by J=E9r=F4me Vouillon... ] >> >> Information hiding is of key importance for making programs more=20 >> readable, secure and maintainable. In particular, for abstraction=20 >> purposes, one would expect to be able to specify freely what methods=20= >> of a class are exported from a package (or a module) to the remainder=20= >> of a program. Furthermore, abstraction should not be impeded by the=20= >> need for complex interaction between objects. For instance, if=20 >> objects from two different classes are to interact with one another,=20= >> it should still be possible to hide the methods involved in the=20 >> interaction. This means that the objects must be able to communicate=20= >> via methods not present in the interfaces exported by the classes to=20= >> the rest of the program. (A class or a function having such a=20 >> privileged access to another class is commonly named a *friend*.) This is what my wish is about. Naturally, my enthusiasm is crushed by=20= the time we reach the concluding paragraph. [ Continuing from the conclusion of the referenced paper... ] >> >> Our calculus does not currently handle multiple inheritance. We hope=20= >> that multiple inheritance is possible even though this might require=20= >> a significantly different semantics. This is another important=20 >> direction for future work. Sigh. I hope this work is continuing. > On the other hand, I have just extended the ocaml type system to allow > the use of private structural types, i.e. abstract types where you > still allow access to some methods. These are cool, but they do not satisfy my principle concerns. The=20 "views" thing seems like the best alternative I've seen so far. Let me=20= put more thought into what is my specific wish to see if I can imagine=20= how to deal with the multiple inheritance problem. -- james woodyatt =