From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p7T3aBMB019874 for ; Mon, 29 Aug 2011 05:36:11 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQCAJAIW07RVaC2imdsb2JhbABCnECLLwgUAQEBCgkNBxIGIYFAAQEBAQMSAhMTBgE4AQMMAQUFDgouNAEFARwGEyKiKgqPEINriSgCAwaFZmAEh2KLPYUOgSiGKzyBRoIw X-IronPort-AV: E=Sophos;i="4.68,295,1312149600"; d="scan'208";a="117479474" Received: from mail-gy0-f182.google.com ([209.85.160.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Aug 2011 05:36:05 +0200 Received: by gyd10 with SMTP id 10so6523854gyd.27 for ; Sun, 28 Aug 2011 20:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+TeK9zp5gke/ObLAKM0sxEpJNSFJkj2HbOX/6tVTq5I=; b=Ebe10u80wmj8iZHk3y20c9jcHAIo8KRcvRqjIr10d2mIhtC86L+bIHSG7nvHznoMQ2 EQlgEBN3delDC8u/3+gfLcUkL3FHp5m5wQXIO8jKnkfYo85n4oMoDN3CoINbKGnYegvx UWDV3iOjEKKgxnA1IXZxkWNrXq1gA4WFGEoJE= Received: by 10.231.55.201 with SMTP id v9mr9446905ibg.16.1314588963981; Sun, 28 Aug 2011 20:36:03 -0700 (PDT) Received: from [192.168.1.212] (nat-10-0.math.nagoya-u.ac.jp [133.6.130.80]) by mx.google.com with ESMTPS id k4sm1522419ibg.14.2011.08.28.20.36.00 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Aug 2011 20:36:02 -0700 (PDT) Sender: Jacques Garrigue Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jacques Garrigue In-Reply-To: <1314486489.3496.179.camel@thinkpad> Date: Mon, 29 Aug 2011 12:35:58 +0900 Cc: Jeff Meister , david.baelde@ens-lyon.org, Chris Yocum , caml-list Message-Id: <61B410B8-15EF-4B18-9CC5-C224FB495353@math.nagoya-u.ac.jp> References: <4E58CCC3.4040901@gmail.com> <1314457588.3496.86.camel@thinkpad> <1314473840.3496.132.camel@thinkpad> <1314486489.3496.179.camel@thinkpad> To: Gerd Stolpmann X-Mailer: Apple Mail (2.1084) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p7T3aBMB019874 Subject: Re: [Caml-list] Ocaml and the Fragile Base Class Problem There are lots of things in this discussion. A first point I would like to make clear: objects are used in ocaml, and quite a lot. You just have to look at the code available. I see them often used to wrap some state, in IO or GUIs. However they are not that much used for what they are often used in C++: program structuring. (There are exceptions: ocamldoc uses lots of inheritance) If you want just to structure your program, modules are better in most cases. There are still situations where classes are stronger than modules for structuring: * when you have a default for some operation, but want to be able to change it * when you want to mix components, using multiple inheritance and virtual methods and instance variables Also, for various reasons, objects are not beginner friendly. I think the main problem is that they don't fit that well with type inference: both subtyping and polymorphic methods require explicit type annotations. This is worse than having long error messages: correct programs (at least programs that would be correct in a really principal type system) get refused for reasons that are hard to understand for beginners. For this reason and others, I think that both objects and polymorphic variants are mostly useful in library design, where you give the user a protocol to use them. This greatly reduces the risk of getting into trouble. On the other hand, I don't think many features are missing from the point of view of expressivity. As I mentioned in my previous mail, ocaml now has an override keyword, and it is a hard error to override a non-defined method. All warnings can be turned into errors, and when programming with objects it is a good idea to activate the ones disabled by default. Concerning friend methods, it is indeed possible to block access at the method level, but I would rather suggest using private rows: module Cell : sig type cell = private < get: int; give: cell -> unit; .. > val create : int -> cell end = struct class cell x = object (_ : 'cell) val mutable x = x method get = x method set y = x <- y method give (c : 'cell) = x <- x - 1; c#set (c#get + 1) end let create = new cell end You cannot inherit from cell, but I would believe this is not a problem in most situations. I see nothing strange in privacy control being at the module level: protected in Java is also at the package level rather than the class level. And it is better not to duplicate functionality. I won't really enter the discussion about information hiding. Encapsulation is central to OO, but whether it is information hiding or not is an open issue :-) Jacques Garrigue On 2011/08/28, at 8:08, Gerd Stolpmann wrote: > Am Samstag, den 27.08.2011, 13:21 -0700 schrieb Jeff Meister: >> I don't understand this part. You can easily hide a public method of >> an object by coercing it to an object type which does not have that >> method. > > Right, but in OO design you build a datastructure often from several > types of objects that communicate closely with each other, and should be > considered as a unit ("friends"). Once you make a method public, > however, it is hard to restrict the access to a friend only. > >> Modules also provide excellent information hiding: if you >> don't want anyone else calling your method, make at least one of its >> input types abstract in the interface, and don't provide any values of >> that type. > > I used this technique in Http_client (part of Ocamlnet). It works but > feels very strange. It's like retrofitting nominal typing into the > structural OO type system. Once you use it, you give up the possibility > that the user creates a totally independent object definition on its > own. The price is quite high, and one also wonders whether objects are > then still useful, or whether a "normal" module with an abstract type > would do better. > > Also, this particular method of information hiding is a feature of the > modules, not of the objects. As such, objects can only hide the inner > state of a single object, which is quite limited. > > Let me point out one final thing. Information hiding is simply not a > core concept of OO - which is in the first place a specific way of > structuring the program (e.g. group data and algorithms together), with > an integrated method of adapting object types (subtyping), and giving > control of parts of your algorithm to the user of your class. This > flexibility and openness is in some contradiction to encapsulation and > access control. This is what I meant with "mindset" - the typical OCaml > programmer likes more the latter (I guess). > > Gerd > >> On Sat, Aug 27, 2011 at 12:37 PM, Gerd Stolpmann wrote: >>> I guess the biggest problem is that structural >>> typing does not offer much for getting information hiding - once a >>> method is public, it is fully public. This is, in some sense, against >>> the mindset of the typical OCaml programmer.