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 FAA06766; Mon, 22 Jul 2002 05:37:42 +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 FAA06655 for ; Mon, 22 Jul 2002 05:37:41 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g6M3bdX03555 for ; Mon, 22 Jul 2002 05:37:40 +0200 (MET DST) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id MAA26744; Mon, 22 Jul 2002 12:37:32 +0900 (JST) To: brian-l-smith@uiowa.edu Cc: caml-list@inria.fr Subject: OCaml's OO design Re: [Caml-list] Protected methods In-Reply-To: <3D39ED57.8010403@uiowa.edu> References: <3D369B89.1030000@baretta.com> <3D39ED57.8010403@uiowa.edu> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020722123732Z.garrigue@kurims.kyoto-u.ac.jp> Date: Mon, 22 Jul 2002 12:37:32 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Brian Smith > 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