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 p7TBKHl8001801 for ; Mon, 29 Aug 2011 13:20:17 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcBAL51W05KfVI0kGdsb2JhbABCDqdoCBQBAQEBCQkNBxQEIYFAAQEBAQMSAhMZARscAQEDDAYFCw0JFg8JAwIBAgEREQEFARwGDQEFAgEBHqI7Cow7glWENTuIbQIDBoZGBI4VhQqFDoEohis8gy85 X-IronPort-AV: E=Sophos;i="4.68,296,1312149600"; d="asc'?scan'208";a="117526091" Received: from mail-ww0-f52.google.com ([74.125.82.52]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Aug 2011 13:20:02 +0200 Received: by wwe6 with SMTP id 6so6808626wwe.9 for ; Mon, 29 Aug 2011 04:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=gFdO9txwmjM6LLoRLgkEa7sOE8UNHnSfnxUQ/9NZxxA=; b=wDx1Msj4F9hqDlZAPuUi9jjVRNXgI5LspFEa1mlPZnsza4iHY5jtAsRXb0QibjqwVa rmJjqQsuocId949Cxk8mOCGyv/A49coySleg1esw0Dp1xdf5qvNfR3NgxQCAMtLSqRFK NGTpKHsAiO6dP3isyasffq0phEjEbfQJ9aS38= Received: by 10.227.207.146 with SMTP id fy18mr3475426wbb.13.1314616801496; Mon, 29 Aug 2011 04:20:01 -0700 (PDT) Received: from [129.215.90.43] (dhcp-90-043.inf.ed.ac.uk [129.215.90.43]) by mx.google.com with ESMTPS id ez4sm3648092wbb.46.2011.08.29.04.19.59 (version=SSLv3 cipher=OTHER); Mon, 29 Aug 2011 04:20:00 -0700 (PDT) Message-ID: <4E5B75DE.2020609@gmail.com> Date: Mon, 29 Aug 2011 12:19:58 +0100 From: Chris Yocum User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Jacques Garrigue CC: Gerd Stolpmann , Jeff Meister , david.baelde@ens-lyon.org, caml-list References: <4E58CCC3.4040901@gmail.com> <1314457588.3496.86.camel@thinkpad> <1314473840.3496.132.camel@thinkpad> <1314486489.3496.179.camel@thinkpad> <61B410B8-15EF-4B18-9CC5-C224FB495353@math.nagoya-u.ac.jp> In-Reply-To: <61B410B8-15EF-4B18-9CC5-C224FB495353@math.nagoya-u.ac.jp> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC6BB3F75A48EEA6D9CE991B9" Subject: Re: [Caml-list] Ocaml and the Fragile Base Class Problem This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC6BB3F75A48EEA6D9CE991B9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Everyone, Thank you very much. This has been enlightening. Apologies for not responding sooner. I didn't know that Ocaml had an override keyword, which fixes this problem, according to the documentation (inherit!, val!, method!). I was wondering if we should fold "Language Extensions" into the main documentation? The actual keywords seem rather terse to me (having an actual "override" keyword would be more explicit and easier to understand). Anyway, again thank you everyone. All the best, Chris On 29/08/11 04:35, Jacques Garrigue wrote: > There are lots of things in this discussion. >=20 > 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. >=20 > 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 ca= ses. > There are still situations where classes are stronger than modules for st= ructuring: > * when you have a default for some operation, but want to be able to chan= ge it > * when you want to mix components, using multiple inheritance and virtual= methods > and instance variables >=20 > Also, for various reasons, objects are not beginner friendly. > I think the main problem is that they don't fit that well with type infer= ence: > 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 reaso= ns that > are hard to understand for beginners. > For this reason and others, I think that both objects and polymorphic var= iants 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. >=20 > 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, an= d 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. >=20 > Concerning friend methods, it is indeed possible to block access at the m= ethod level, > but I would rather suggest using private rows: >=20 > module Cell : sig > type cell =3D private < get: int; give: cell -> unit; .. > > val create : int -> cell > end =3D struct > class cell x =3D object (_ : 'cell) > val mutable x =3D x > method get =3D x > method set y =3D x <- y > method give (c : 'cell) =3D > x <- x - 1; > c#set (c#get + 1) > end > let create =3D new cell > end >=20 > You cannot inherit from cell, but I would believe this is not a problem i= n most situations. > I see nothing strange in privacy control being at the module level: prote= cted > in Java is also at the package level rather than the class level. And it = is better > not to duplicate functionality. >=20 > I won't really enter the discussion about information hiding. > Encapsulation is central to OO, but whether it is information hiding or n= ot is > an open issue :-) >=20 > Jacques Garrigue >=20 > 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. >=20 >=20 --------------enigC6BB3F75A48EEA6D9CE991B9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk5bdeEACgkQDjE+CSbP7Hoc/gD/d9kmaxRlAGMp7ojdL5FLwC8j bNSP7OwcVSPf8+oQtGMA/iBapeoDFSvMS230rsbYjEmR2DfBywxm/B4NHwc7YF2r =I7Zk -----END PGP SIGNATURE----- --------------enigC6BB3F75A48EEA6D9CE991B9--