OCaml's OO design Re: [Caml-list] Protected methods

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: Brian Smith <brian-l-smith@uiowa.edu>
> Dmitry Bely wrote:
>  > Do not private Ocaml methods have in fact "protected" C++ semantics?
>  > They cannot be called directly but can be used in methods of inherited
>  > classes...
> 
> This was my impression as well. I think it would be a good idea to add
> something to the FAQ about how UML-ish/Java-ish
> private/protected/public/package visibility maps to O'Caml. And, if
> there isn't a direct mapping in some cases, then perhaps explanations of
> "workarounds" like the ones presented in this thread.

That would be certainly useful.
Unfortunately, my understanding of these issues is only partial, as
for most developpers of ocaml: they are much better at type theory of
O.O. than the quirks of each O.O. language.

OK, let's try:
Java                            OCaml
private                         private + hidden by interface
protected/subclasses only       private
default=package protected       public + type abstraction
protected                       public + type abstraction + export class
public                          public

Hidden by interface means defining a class type with some private
methods omitted.
Type abstraction means the workaround I presented earlier in this
thread, combining subtyping to hide methods, and use of an abstract
type to access hidden methods. You can choose to export or not the
class, to allow subclassing outside of the module.
However, if you want to enforce package protection for individual
methods while exporting the class, you have to abstract the type of
the method itself (Gerd Stolpmann's trick is not enough to avoid
redefinition):
        type hidden = ...
        method m : m_hidden

Why is ocaml's typing so different from other typed OO languages?
Essentially, this is because it chose a radically different
theoretical fundation, with structural rather than by-name typing.
This means that unrelated classes may have the same class type!
I believe this choice comes from another, more primitive choice, of
building object-polymoprhism on parametric polymorphism rather than
subtyping.

This provides for a very powerful language (at least in theory), where
you can type safely more OO programs and idioms than in any other
"usable" language.  But this also means some rough edges, as the basis
is rather experimental.

By the way, my experience with ocaml makes me think that the current
design is at least wrong on one point: mixing classes and class types.
As written above, two unrelated classes may have the same class type,
so there is no point in creating a class type for each class (it is
not "owned" by the class).
And a bad consequence of this choice is all these "unbound type
variable" errors, which are just due to the need to define a class
type.
By separating the two, and making classes first-class, one could clean
up some things, and for instance allow defining a class anywhere in an
expression (you would want to do a bit of lambda-lifting for
efficiency).

On the other hand, I also understand why it was designed that way:
abbreviating types is essential to get understandable error messages,
and this would have to be done explicitely, which some might find
verbose.
Yet, I wonder whether the separation would be a worthwhile (extensive)
change.

Cheers,

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