Re: [Caml-list] wish for something like 'restricted' methods

[james woodyatt <jhw@wetware.com>]

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 
asking for something that better supports "friend" relationships.  My 
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 
> 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 
it carefully.  I'm pretty sure I followed the math without getting 
lost.  The paper appears to cover *exactly* the problem that concerns 
me-- for precisely the reasons mentioned in its introductory section.  
My notion of "restricted" methods is a somewhat limited subset of what 
his "views" describe more generally.

[ From the paper referenced above by Jérôme Vouillon... ]
>>
>> Information hiding is of key importance for making programs more 
>> readable, secure and maintainable.  In particular, for abstraction 
>> purposes, one would expect to be able to specify freely what methods 
>> of a class are exported from a package (or a module) to the remainder 
>> of a program.  Furthermore, abstraction should not be impeded by the 
>> need for complex interaction between objects.  For instance, if 
>> objects from two different classes are to interact with one another, 
>> it should still be possible to hide the methods involved in the 
>> interaction.  This means that the objects must be able to communicate 
>> via methods not present in the interfaces exported by the classes to 
>> the rest of the program.  (A class or a function having such a 
>> privileged access to another class is commonly named a *friend*.)

This is what my wish is about.  Naturally, my enthusiasm is crushed by 
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 
>> that multiple inheritance is possible even though this might require 
>> a significantly different semantics.  This is another important 
>> 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 
"views" thing seems like the best alternative I've seen so far.  Let me 
put more thought into what is my specific wish to see if I can imagine 
how to deal with the multiple inheritance problem.


--
james woodyatt <jhw@wetware.com>