From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p7RN8IZ1010580 for ; Sun, 28 Aug 2011 01:08:18 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMBAD54WU7U4367kWdsb2JhbABChEyjQxQBAQEBCQsLBxQDIoFAAQEEASNWBQsLDgoCAiYCAlcGEwmHaQICp3WQLoEshA+BEQSMB4wmi3g X-IronPort-AV: E=Sophos;i="4.68,291,1312149600"; d="scan'208";a="106836890" Received: from moutng.kundenserver.de ([212.227.126.187]) by mail4-smtp-sop.national.inria.fr with ESMTP; 28 Aug 2011 01:08:12 +0200 Received: from office1.lan.sumadev.de (dslb-084-059-070-124.pools.arcor-ip.net [84.59.70.124]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0M5IfX-1R9sG51fgN-00ys3q; Sun, 28 Aug 2011 01:08:10 +0200 Received: from [192.168.1.111] (546BF154.cm-12-4d.dynamic.ziggo.nl [84.107.241.84]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 0629EC00C7; Sun, 28 Aug 2011 01:08:09 +0200 (CEST) From: Gerd Stolpmann To: Jeff Meister Cc: david.baelde@ens-lyon.org, Chris Yocum , caml-list@inria.fr In-Reply-To: References: <4E58CCC3.4040901@gmail.com> <1314457588.3496.86.camel@thinkpad> <1314473840.3496.132.camel@thinkpad> Content-Type: text/plain; charset="UTF-8" Date: Sun, 28 Aug 2011 01:08:09 +0200 Message-ID: <1314486489.3496.179.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:x3W1zWrTTtAO29el7cbBWPHpQs3zUNE+oTEXJML9MGE S1MBXs6Nbt8UZT8txJIqjXid7IdcgiZEuJGioe64v9kgoQ0wO7 +8L9afuyft50z1gjaZwhxKcoYZXMI7nMmVyqK2D7jvj+aoFA0e mRtz1EkHCCpDhtIPkjTsOhvyo+z/cNO5ZqGCJVHl/KdqtdO8dB zlSshv+dUwNiRG58cMcIw== Subject: Re: [Caml-list] Ocaml and the Fragile Base Class Problem 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. > -- ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. ------------------------------------------------------------