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

[Jacques GARRIGUE <garrigue@math.nagoya-u.ac.jp>]

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