Re: [Caml-list] Type notation in OO-layer

[Julien Moutinho <julien.moutinho@gmail.com>]

On Fri, Aug 03, 2007 at 11:18:41PM +0200, Oliver Bandel wrote:
> value_as_string has type "string", but that is not completely correct, because
> it get's no input-value, and therefore is of type "unit -> string".
Nop, this is correct, a little bit strange, at a pinch,
because at first sight one could think about this as
a field access (i.e. like r.contents), thus without any possibility
to wrap code around it; but it may not be the case.

> One could say, that this is a special notation for OO, but
> if we are rigid (we should be! ... shouldn't we?!) it is not correct.
Ocaml being a multi-paradigms language, I do not see any problem, even moral.
This is just not functional at the user level, that's all.
I think the main reason is to enable a clean cascading of the methods
(i.e. o#m1#m2#...) coupled with a ``right-most precedence'' of '#'
but since I was not around by the time the Inrians were designing it,
and that my flying over [1] was as unsuccessful as my grepping at the old caml-list,
I do not know.
Long ago, I had a glance at [0]. Now, I am still wondering why it has remained unanswered,
but mostly if a cool Camlp(4|5) extension could easily do the same job?
Will see later, unless List.exists will_spoil_us [`Mr_Pouillard; `Mr_De_Rauglaudre; `Mr_Doe].

> As it is not a true "unit"-function, we at least should give it a
> unit-like type like "message -> string" so that the type-system
> make a complete annotation of type?!
Don't worry, what you call ``message'' is already symbolized by the name of the method.
Roughly, at runtime the ``obj#meth_name'' notation uses the name of the method
and a table carried by the object to retrieve the code to be executed (cf. [2]).
Note that the name of the method appears in the type of the object.

> Why is the "sending a message to the [object]" activity not
> notated in the type?
Don't panic, just an habit to get.

> And: are both definitions correctly?
AFAIK, yep. Unless you are following a coding guideline telling you
to use the first way when the method does a certain kind of thing,
and the second when it does an other kind.
Example:
  no unit = the returned value is definitively set at the instantiation of the class
  use of unit = the returned value may change after the instantiation

> Which to choose?  Preferences in style?
The unit way:
  +++++ the method is /easily/ extensible with optional arguments
  +     the functional property could be helpful to delay the application
        of a method easily without any wrapping:
        instead of (fun () -> o#destroy) you just write o#destroy.
  --    more parentheses:
        instead of o#method1#method2#... you must write in vanilla Ocaml:
        ((o#method1 ())#method2 ())#...
  -     perhaps a little runtime overhead, but mostly /negligible/

Therefore, in my mind I have shaped it in an easy trade-off between extensibility and meaning.
Only simple methods, whose job and use are well known /à priori/, mostly accessors
of values but also methods like #clone, #destroy, or #nocopy /à la/ LablGTK may get
my agreement to avoid the added unit.

Note that the same concern arises with the definition of classes.

Hope this helps you a lOt to surround the "Ocaml".[0].

Oh, and by the way, here are two opinions I would have liked to know
by the time I was learning Ocaml objects, and thus using them /everywhere/...

Opinion of an Inrian, who worked on this famous char [2]:
    "OCaml is first a functional lang[u]age so I think (I hope) that people do
  not use objects as heavily as in Java, and for instance use pattern
  matching rather than only method calls for implementing branches."

Opinion of an Academian who has worked with Ocaml [3]:
    "I suspect that continued exposure to OCaml will
  eventually induce developers to design programs that are written al-
  most entirely in the functional style, if only because these aspects
  of the language are the most mature and the most widely used. I
  am personally beginning to find that writing in the functional style
  leads to far fewer bugs, simply because most of the program data is
  immutable and thus there is little room for errors involving incon-
  sistent state."

References:
[0]: Mr.Boos' proposal:
  http://caml.inria.fr/pub/ml-archives/caml-list/1996/10/1d280be49dcb480ce0fa1428e668e330.en.html
[1]: Mr.Vouillon and Mr.Remy's paper:
  http://caml.inria.fr/pub/papers/remy_vouillon-objective_ml-tapos98.ps.gz
[2]: Mr.Vouillon's opinion:
  http://gallium.inria.fr/~doligez/caml-guts/objects.txt
[3]: Mr.DiBernardo's opinion:
  https://www.cs.ubc.ca/~kdvolder/CPSC511/submissions_06_07/mike.pdf
[4]: Mr.Mottl's thoughts:
  http://caml.inria.fr/pub/ml-archives/caml-list/1999/06/2691901a1d9946772870ac5f96552341.en.html