Just as a note, I think the major barrier to the "friend" behavior of
"protected" and "private" in Java (that is, methods of the appropriate
classes are able to call a given method even though other pieces of
code cannot see that it exists) is that subtyping and subclassing are
independent.

In Java, if you are handed a value of a given type and know that type
is a subclass of the "Foo" class, you *know* that it has all the
methods (hidden and not hidden) that a Foo has.  In O'Caml, this
luxury is not available.  If the object type of foo does not indicate
that a method "bar" exists, it may very well not exist.

This is why you need to do a song and dance with abstract types to
achieve the same effect.  The method *must* be visible or other
objects can't call it, since it is *only* the type of an object that
defines its interface.  Using type abstraction means that only code
that knows the underlying type has access, which allows you to show
that the method is there and has the right type, while not allowing
access to everybody.

Does this feel clunky?  Yes, a little bit.  But it's a price I'm
willing to pay for structural subtyping and self types.  I think it
calls to mind some of the subtler problems with subclassing and
subtyping--like invariants.  If you call a "protected" method in Java,
it generally means you're depending on the subclass to maintain
invariants from the superclass.  But all too often, this can lead to
problems where modularity breaks down.

Bondage programming?  Yeah, could be.  :) But it has some interesting
typing properties rarely found elsewhere, and makes us think about a
different set of implications in object calculi than most languages.
Consider learning to work within these constraints to be working in a
different programming paradigm than Java or C++ provides--because it
clearly is.  Different idioms are needed.  Some possibilities that
were closed off become open, and some that were open are now more
constrained.

It's, quite honestly, a load of fun.

John.
-------------------
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