Re: [Caml-list] Ocaml and the Fragile Base Class Problem

[Chris Yocum <cyocum@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5820 bytes --]

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.
> 
> 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 <info@gerd-stolpmann.de> 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.
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]