From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id GAA07207; Mon, 22 Jul 2002 06:13:24 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 GAA07195 for ; Mon, 22 Jul 2002 06:13:23 +0200 (MET DST) Received: from laurelin.dementia.org ([208.167.88.73]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g6M4DMX03928 for ; Mon, 22 Jul 2002 06:13:22 +0200 (MET DST) Received: by laurelin.dementia.org (Postfix, from userid 1001) id 4C11170C0; Mon, 22 Jul 2002 00:20:18 -0400 (EDT) To: caml-list@inria.fr Subject: Re: OCaml's OO design Re: [Caml-list] Protected methods References: <3D369B89.1030000@baretta.com> <3D39ED57.8010403@uiowa.edu> <20020722123732Z.garrigue@kurims.kyoto-u.ac.jp> From: John Prevost Date: 22 Jul 2002 00:20:18 -0400 (18.076 UMT) In-Reply-To: <20020722123732Z.garrigue@kurims.kyoto-u.ac.jp> Message-ID: <86y9c4s8al.fsf@laurelin.dementia.org> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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