Type notation in OO-layer

Type notation in OO-layer

[Oliver Bandel]

Hello,

please look at this very simple OO-stuff
to discuss a question I have, regarding the
notation (and / or behaviour) of the OO-layer
in OCaml:




=======================================================
oliver@siouxsie2:~/ocaml-oo$ cat verysimple.ml
class simple_1 =
  object
    val mutable mutval = 12

    method get = mutval

    method set x = mutval <- x

    method value_as_string = Printf.sprintf "value_as_string: %d" mutval
    method vas ()          = Printf.sprintf "vas:             %d" mutval
  end

let iprint i = Printf.printf "iprint: %d\n" i


let example_s1 = new simple_1


let _ =
  let o_1 = new simple_1 in

  iprint (o_1 # get);
  print_endline (o_1 # value_as_string);
  print_endline (o_1 # vas());
  o_1#set 77;
  iprint (o_1 # get);
  print_endline (o_1 # value_as_string);
  print_endline (o_1 # vas());
  ()
oliver@siouxsie2:~/ocaml-oo$ ocaml verysimple.ml
iprint: 12
value_as_string: 12
vas:             12
iprint: 77
value_as_string: 77
vas:             77
oliver@siouxsie2:~/ocaml-oo$ ocamlc -i  verysimple.ml
class simple_1 :
  object
    val mutable mutval : int
    method get : int
    method set : int -> unit
    method value_as_string : string
    method vas : unit -> string
  end
val iprint : int -> unit
val example_s1 : simple_1
oliver@siouxsie2:~/ocaml-oo$


=======================================================


As you can see, the methods "value_as_string"
and "vas" are intended to do the same: giving back
a string, that will be created from the internal int-value.

Following the non-OO programming in OCaml,
vas() should be the right way to do it, because
the method get's no arg.
Following the OO-like way, value_as_string should be OK also.

What would be the right way?

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


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.

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?!

Why is the "sending a message to the method" activity not
notated in the type?

And: are both definitions correctly?
Which to choose? Preferences in style?

TIA,
   Oliver

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

[Oliver Bandel]

Zitat von Oliver Bandel <oliver@first.in-berlin.de>:

[...]
> 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?!


OK, I had misleading thoughts here: not the method get's the message,
the object gets the message.

So, the type of the function is OK.
But shouldn't the message be somewhere else notated?

Or is this thrown out in general, when using OO?

I sthere no contradiction, when using such a type annotation,
when comparing it to the non-OO stuff?


TIA,
   Oliver

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

[Jacques GARRIGUE]

From: Oliver Bandel <oliver@first.in-berlin.de>
> Zitat von Oliver Bandel <oliver@first.in-berlin.de>:
> 
> [...]
> > 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?!
> 
> 
> OK, I had misleading thoughts here: not the method get's the message,
> the object gets the message.
> 
> So, the type of the function is OK.
> But shouldn't the message be somewhere else notated?
> 
> Or is this thrown out in general, when using OO?
> 
> I sthere no contradiction, when using such a type annotation,
> when comparing it to the non-OO stuff?

The object-oriented view that objects "understand" messages is somewhat
confusing, because it makes unclear where the code is. More directly,
a method call is decoded as:

   obj#meth == obj.meth obj

So, as you have correctly noted, since any method is getting the object
itself as argument, any method call contains a function application,
and the value it returns need not be always the same.
However, this may also be confusing and/or not practical at times.
For instance, what is the meaning of a method of type only "unit" ?

The approach used in lablgtk for instance is to have all
side-effecting methods take at least one argument. Taking unit as an
argument is useful at times, for instance if you want to use it as a
callback (i.e. if you want to make a closure of a method call).
On the other hand, accessors to mutable values do not take unit as
argument. This reflects the fact we use the same syntax for both
mutable and immutable fields in records.
While I think this distinction between side-effecting and non
side-effecting methods is useful, there is no way to have the language
verify it (you would have to know it for functions too...), and some
people might not like the extra argument, so this is difficult to make
it a hard rule.

Jacques Garrigue

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

[Julien Moutinho]

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