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 <[email protected]>
>> 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.
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
