]> 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