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

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

[Chris Yocum]

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

Hello,

A friend of mine is giving a talk about "monkey patching" entitled
"Monkey patching, subclassing, and accidental overriding"
(http://aaroncrane.co.uk/talks/monkey_patching_subclassing/paper.html).
 I was wondering how Ocaml deals with this situation or if it is even a
problem at all in Ocaml?  I mocked up some code:

class base =
object
  method meth x =
    print_endline "base";
    print_endline (string_of_int x)
end

class deriv =
object
  inherit base
  method meth x =
    print_endline "deriv";
    print_endline (string_of_int x)
end

which kind of(?) shows the problem in Ocaml.  He suggests in his paper
that using a Meta-Object Protocol is the way around this.  What do you
think?

Thanks,
Chris Yocum


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

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

[Jacques Garrigue]

On 2011/08/27, at 19:53, Chris Yocum wrote:

> A friend of mine is giving a talk about "monkey patching" entitled
> "Monkey patching, subclassing, and accidental overriding"
> (http://aaroncrane.co.uk/talks/monkey_patching_subclassing/paper.html).
> I was wondering how Ocaml deals with this situation or if it is even a
> problem at all in Ocaml?  I mocked up some code:
> 
> class base =
> object
>  method meth x =
>    print_endline "base";
>    print_endline (string_of_int x)
> end
> 
> class deriv =
> object
>  inherit base
>  method meth x =
>    print_endline "deriv";
>    print_endline (string_of_int x)
> end
> 
> which kind of(?) shows the problem in Ocaml.  He suggests in his paper
> that using a Meta-Object Protocol is the way around this.  What do you
> think?


You can require overriding to be explicit by activating warning 7:

$ ocaml -w +7
        OCaml version 3.13.0+dev6 (2011-07-29)

# class c = object method x = 1 end;;
class c : object method x : int end
# class d = object inherit c method x = 2 end;;
Warning 7: the method x is overridden.
class d : object method x : int end

Note also that in ocaml a method only has one signature,
so the problems with API changes doesn't apply here:
you get an error if the type changed in the base class,
and a warning if the method name was changed in the base class.

However, in this respect I think that a "final" keyword is missing in ocaml.
Namely, you have no way to say that you don't want subclasses to modify
a method (because you want to be able to redefine it yourself, for instance).
But OCaml is not an object-only language, so if you want this kind of
guarantee you can use functors: specify exactly what the user should provide,
without allowing a posteriori overriding.

Jacques Garrigue

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

[Gerd Stolpmann]

Am Samstag, den 27.08.2011, 11:53 +0100 schrieb Chris Yocum:
> Hello,
> 
> A friend of mine is giving a talk about "monkey patching" entitled
> "Monkey patching, subclassing, and accidental overriding"
> (http://aaroncrane.co.uk/talks/monkey_patching_subclassing/paper.html).
>  I was wondering how Ocaml deals with this situation or if it is even a
> problem at all in Ocaml?  I mocked up some code:
> 
> class base =
> object
>   method meth x =
>     print_endline "base";
>     print_endline (string_of_int x)
> end
> 
> class deriv =
> object
>   inherit base
>   method meth x =
>     print_endline "deriv";
>     print_endline (string_of_int x)
> end
> 
> which kind of(?) shows the problem in Ocaml.  He suggests in his paper
> that using a Meta-Object Protocol is the way around this.  What do you
> think?

I think it is a non-issue in practice. Simply because inheritance is
quite seldom in Ocaml, even in programs using a lot of OO features.
There is an attractive alternative, namely passing functions down to
change the behavior of objects. So, you would normally define

class base ?meth () =
object
  method meth x =
    match meth with
      | None ->
          print_endline "base";
          print_endline (string_of_int x)
      | Some f ->
          f x
end

class deriv = 
  base ~meth:(fun x ->
                print_endline "deriv";
                print_endline (string_of_int x)
             )
       ()

You'd do something like this for all mutable behavior (maybe you
wouldn't use individual functions for overriding, but some more
elaborate data structure). Of course, this is generally a less powerful
technique, but you often don't need the full power of inheritance. This
is attractive for getting more control, and looks less like patching the
algorithms of the base class.

Also, you don't need inheritance in Ocaml for declaring subtyping
relations. So, it is entirely possible to avoid the "inherit" keyword,
and have nevertheless a lot of object-oriented design.

Gerd

> 
> Thanks,
> Chris Yocum
> 

-- 
------------------------------------------------------------
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.
------------------------------------------------------------

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

[David Baelde]

On Sat, Aug 27, 2011 at 5:06 PM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> I think it is a non-issue in practice. Simply because inheritance is
> quite seldom in Ocaml, even in programs using a lot of OO features.

Perhaps the issue is the reason why we don't use more OO in OCaml?
That kind of problem did bit us once. It's particularly dangerous when
combined with recursive methods -- when you override, it breaks
recursion.

David

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

[Gerd Stolpmann]

Am Samstag, den 27.08.2011, 18:59 +0200 schrieb David Baelde:
> On Sat, Aug 27, 2011 at 5:06 PM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> > I think it is a non-issue in practice. Simply because inheritance is
> > quite seldom in Ocaml, even in programs using a lot of OO features.
> 
> Perhaps the issue is the reason why we don't use more OO in OCaml?
> That kind of problem did bit us once. It's particularly dangerous when
> combined with recursive methods -- when you override, it breaks
> recursion.

Right, but as noted, you can easily live without inheritance in OCaml.

I can only speculate why OO is not that much used in OCaml. I've got the
impression that the "disliked" feature is not object-orientation as
such, but the structural typing (which includes polymorphic variants,
which I also see rarely). 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. Second, there are practical
difficulties - sometimes very long error messages (1000 lines and more),
and surprising weak spots in the type checker (e.g. when a method has
optional arguments). OO is definitely nothing for OCaml beginners.

Nevertheless, I think that there are very good examples of OO in OCaml.
For instance, any kind of I/O device or I/O processor - which usually
profit a lot from dynamic binding and subtyping, and for which
information hiding is not an issue (you communicate with the system).
For this reason there is a lot of OO in OCamlnet. Strange enough, I
count as "OO guy" in the OCaml scene, although I don't use it much
outside the context of I/O operations.

Let me reformulate your question: We should better ask which OO design
patterns are still adequate in OCaml. Obviously, many textbook design
patterns feel strange in OCaml - the language has simply better
alternatives. The remaining interesting cases seem to always use dynamic
binding and optionally subtyping.

Gerd
> 
> David
> 

-- 
------------------------------------------------------------
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.
------------------------------------------------------------

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

[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. 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.

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.

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

[Gerd Stolpmann]

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.
> 

-- 
------------------------------------------------------------
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.
------------------------------------------------------------

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

[Andreas Rossberg]

On Aug 28, 2011, at 01.08 h, Gerd Stolpmann wrote:
>
> 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.

Not sure why you would say that. I'd argue that information hiding  
("encapsulation") definitively is very central to OO -- an object  
collects a set of methods that operate on some hidden shared state  
(not necessarily mutable). And Ocaml fully supports that.

What is not at the core of OO is the kind of ad-hoc softening of full  
encapsulation introduced by access modes like "protected" or "friend".  
And for better or worse, that's what Ocaml does not support directly  
-- everything is either public or (instance) private, unless you  
encode more sophisticated policies through the module system.

/Andreas

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

[Guillaume Yziquel]

Le Sunday 28 Aug 2011 à 11:31:35 (+0200), Andreas Rossberg a écrit :
> On Aug 28, 2011, at 01.08 h, Gerd Stolpmann wrote:
> >
> >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.
> 
> Not sure why you would say that.

Information hiding and extensibility via C++ virtual member functions
are orthogonal concepts. It seems to me that, historically, the benefit
of OO was essentially code organisation and reusability. Making it
"easier" was the main benefit over C. Compared to that, information
hiding isn't that great of a benefit compared to what you could already
do in C. In a sense, information hiding is more of a refinement, and not
the core concept of OO.

At least that my take on it.

-- 
     Guillaume Yziquel

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

[Gerd Stolpmann]

Am Sonntag, den 28.08.2011, 11:31 +0200 schrieb Andreas Rossberg:
> On Aug 28, 2011, at 01.08 h, Gerd Stolpmann wrote:
> >
> > 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.
> 
> Not sure why you would say that. I'd argue that information hiding  
> ("encapsulation") definitively is very central to OO -- an object  
> collects a set of methods that operate on some hidden shared state  
> (not necessarily mutable). And Ocaml fully supports that.

Who says that the state is or can be hidden? This is certainly a later
addition to OO, when people found out that they can view a class as an
abstract data type (with the known limitations). Take off your "typed
glasses". OO is mainly a way of organizing the execution flow, and there
are lots of OO languages lacking typing and access control. And even in
OCaml you'd not use objects if your primary interest is encapsulation -
objects are not good at this. (That's all what I'm saying!)

Gerd

> What is not at the core of OO is the kind of ad-hoc softening of full  
> encapsulation introduced by access modes like "protected" or "friend".  
> And for better or worse, that's what Ocaml does not support directly  
> -- everything is either public or (instance) private, unless you  
> encode more sophisticated policies through the module system.
> 
> /Andreas
> 
> 

-- 
------------------------------------------------------------
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.
------------------------------------------------------------

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

[Andreas Rossberg]

On Aug 28, 2011, at 12.11 h, Gerd Stolpmann wrote:
> Am Sonntag, den 28.08.2011, 11:31 +0200 schrieb Andreas Rossberg:
>> On Aug 28, 2011, at 01.08 h, Gerd Stolpmann wrote:
>>>
>>> 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.
>>
>> Not sure why you would say that. I'd argue that information hiding
>> ("encapsulation") definitively is very central to OO -- an object
>> collects a set of methods that operate on some hidden shared state
>> (not necessarily mutable). And Ocaml fully supports that.
>
> Who says that the state is or can be hidden? This is certainly a later
> addition to OO, when people found out that they can view a class as an
> abstract data type (with the known limitations). Take off your "typed
> glasses". OO is mainly a way of organizing the execution flow, and  
> there
> are lots of OO languages lacking typing and access control.

Again, I don't follow. Alan Kay claims that he invented the term, and  
his vision of OO was basically that of black boxes communicating  
through messages. AFAICS, that's also the common picture in OOAD  
literature. Whether one buys into that is a different story.

Also, none of that has anything to do with types. Objects-as-records- 
of-closures are a sufficient and pretty natural implementation of this  
concept.

> And even in
> OCaml you'd not use objects if your primary interest is  
> encapsulation -
> objects are not good at this. (That's all what I'm saying!)

I agree. Modules are superior for most day-to-day things. But then  
again, a first-class module is pretty much an object with type  
members, and sometimes one wants first-class modules. ;)

/Andreas

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

[Julien Signoles]

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

Hello,

2011/8/27 Gerd Stolpmann <info@gerd-stolpmann.de>

> I can only speculate why OO is not that much used in OCaml.  Second, there
> are practical
> difficulties - sometimes very long error messages (1000 lines and more),
> and surprising weak spots in the type checker (e.g. when a method has
> optional arguments).
>

I don't think that OO is not that much used because error messages may be
long: there is the same issue with the module system which is now quite
widely used. Personally I'm not so unhappy with a 1.000 lines-long error
message : last Friday again, I get an error message with many more than
100.000 lines (when compiling a file with less than 1.000 lines of code): it
took several minutes to be printed and few seconds to be fixed: the 2 last
lines of the message was the familiar "values do not match val v: tau1 is
not included in val v: tau2" which was easy to fix in that case...

--
Julien

[-- Attachment #2: Type: text/html, Size: 1467 bytes --]

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

[Jacques Garrigue]

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.

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

[Chris Yocum]

[-- 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 --]

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

[Guillaume Yziquel]

Le Monday 29 Aug 2011 à 12:19:58 (+0100), Chris Yocum a écrit :
> 
> I was wondering if we should fold "Language Extensions" into the main
> documentation?

To my understanding, "Language Extensions" refers to part of the
language that may evolve in future versions, as opposed to the core
language which is supposed to be more stable. So this distinction does
make sense. Now a few pointers in the main documentation to sections in
"Language Extensions" aren't a bad idea either.

-- 
     Guillaume Yziquel

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

[Chris Yocum]

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

There are some parts in there that go back to Ocaml 1.00.  I doubt that
they will change anytime soon.  Anyway, linking is a good idea.

Chris

On 29/08/11 12:47, Guillaume Yziquel wrote:
> Le Monday 29 Aug 2011 à 12:19:58 (+0100), Chris Yocum a écrit :
>>
>> I was wondering if we should fold "Language Extensions" into the main
>> documentation?
> 
> To my understanding, "Language Extensions" refers to part of the
> language that may evolve in future versions, as opposed to the core
> language which is supposed to be more stable. So this distinction does
> make sense. Now a few pointers in the main documentation to sections in
> "Language Extensions" aren't a bad idea either.
> 


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

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

[Alain Frisch]

On 8/29/2011 5:35 AM, Jacques Garrigue wrote:
> 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

I second that.  We are moving some parts of our code base to a mixin 
style implemented with multiple inheritance, virtual methods, 
constraints, very rare overridding (and no instance variables).  This 
results in drastic reduction of code size compared to our previous 
approach where code sharing between components was implemented with 
simple function calls.   The code is also easier to evolve.

We create objects (without state) to represent bags of properties 
computed from parameters; each method represents a property. An object 
is created by assembling reusable mixins (inheritance) and implementing 
remaining virtual methods.  Once the object is created, we observe a few 
properties and throw the object away.  In effect, we use objects to 
describe purely functional computation graphs, with reusable sub-graphs. 
  (Most methods don't take argument; in order to avoid repeated 
evaluation, we have a special hack which rewrites an object's method 
table so as to give its methods a lazy behavior.)

The nice thing with this approach is that the object layer does all the 
plumbing automatically. Combining several reusable components does not 
require to pass data around from one component to another explicitly. 
The old style with functions required to pass many arguments, 
deconstruct the result (a component typically computes several things), 
organize reusable components to avoid mutual recursions, and define many 
data types (records to represent the result of components).  In some 
cases, a large amount of the code was caused by such plumbing.


> 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.

Time to advertise the implicit-subtyping branch?


-- Alain

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

[Jacques Garrigue]

On 2011/09/01, at 6:33, Alain Frisch wrote:
>> 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.
> 
> Time to advertise the implicit-subtyping branch?

Indeed the implicit-subtyping branch helps: if the compiler knows all the types,
it doesn't force you to write a coercion by hand.
On the other hand, this is only a partial solution, as my comment was on the
lack of principality: you still need type annotations in many cases.
Constraint-based type inference might recover this principality, but since the types
inferred get even worse than with structural object types, I'm afraid this is not
really practical. (It might work better with nominal subtyping.)

Jacques Garrigue