[Caml-list] Confusion about chapter 3 in the OCaml manual

[Caml-list] Confusion about chapter 3 in the OCaml manual

[Ishmael Yavitz]

I am a relative new-comer to the OCaml language, but so far I've
enjoyed using it.  I'm currently going through the manual, attempting
to understand everything from start to finish.  Chapter 3 has been
particularly confusing to me.  Rather than keeping my confusion
(ignorance? <grin>) private, I decided to release it to the list.

I hope that the outcome will be two-fold: that some kind soul will
cure my confusion, and that my confusion can be employed to clarify
the manual, therefore helping those who come after me.

I should note to those who would be so kind as to reply that I
"speak" several programming languages, among them object-oriented
ones and functional ones.  I'd like to think that I am knowledgeable
about programming, but I must admit that the manual has gotten the
best of me.

I want to contribute to the OCaml community, but as I am not yet
learned in OCaml, I hope that these comments can be my contribution
for now.


COMMENTS ON CHAPTER 3 OF THE OBJECTIVE CAML MANUAL
(10 DEC 2001 RELEASE)

Section 3.1 - Classes and Objects

After the definition of the class point and an instantiation of the
class, the text reads, " [point] stands for the object type
<get_x : int; move : int -> unit>, listing the methods of class point
along with their types."  Should this be taken to mean that an object
type is defined by its methods, and not at all by its member variables?
Are classes with exactly the same methods then somehow equivalent?

Why is the type of the class "point" printed as in the above excerpt,
when after entering the definition the interpreter returns

class point :
object method get_x : int method move : int -> unit
val mutable x : int end


It seems to me that the above suggests that the member variables (x in
this case) are a part of the type of the class, not just the methods,
as was suggested above.  Is this correct?


Section 3.5 - Private methods

Below the definition of the restricted_point class and some examples
is the sentence, "Private methods are inherited (they are by default
visible in subclasses), unless they are hidden by signature matching,
as described below."  Where is the signature matching described?  If
I understand correctly, (I did execute the code) the rest of the
examples in the section describe how to make a previously private
method public in a child class, not how to hide it.  How can one hide
a method so it can't become public in a child class?

In the first definition of point_again appears the line

object (self : < move : _; ..> )

but what exactly does this line mean?

After the first definition of point_again is the paragraph, "One
could think that a private method should remain private in a subclass.
However, since the method is visible in a subclass, it is always
possible pick its code and define a method of the same name that run
that code, so yet another (heavier) solution would be..."  This was
initially extremely confusing to me.  Prior text (quoted above) reads,
"Private methods are inherited (they are by default visible in
subclasses), unless they are hidden by signature matching, as
described below."  Until I had access to a computer to execute the
code, I assumed that when the text spoke about a "(heavier) solution"
it was referring to the problem of hiding a method so it can't become
public in a sub-class.  So in this context, the "problem" is how to
make a method become public, not how to hide a method?  Also, what
does "heavier" mean in this context?

Another question: the class definition the above text refers to is

class point_again x =
  object (self : < move : _; ..> )
    inherit restricted_point x as super
    method move = super#move
  end;;

Don't the

  object (self : < move : _; ..> )

and

    method move = super#move

instructions both accomplish the same goal?  Is it necessary to use
both?


Section 3.6 - Class interfaces

After the definition of the class restricted_point_type appears the
text, "Both instance variables and concrete private methods can be
hidden by a class type constraint. Public and virtual methods,
however, cannot."  I don't understand what this means.  Is this
referring to the hiding of methods that was mentioned briefly in
the previous section?


Section 3.7 - Inheritance

Near the end of the section appears the text, "Methods need not be
declared previously, as shown by the example..."  I don't understand
this sentence.  Does this mean that after the following instruction:

#let set_x p = p#set_x;;

set_x can be applied to any object that has a set_x method?


Section 3.8 - Multiple inheritance

It is my understanding that multiple inheritance refers to a class
that inherits directly from more than one class.  (For example, class
colored_line inherits from both the class color and the class line.)
Some languages do not permit this because of problems - for example,
when both parents have a method or member variable of the same name,
which one should be used in the child?  What does "multiple
inheritance" refer to in the manual text?

At the end of this section is the sentence, "A private method that has
been hidden in the parent class is no longer visible, and is thus not
overridden." Is this the same "hiding" that was discussed previously?
Again, I'm not sure how to do this hiding, and have not found in the
manual where it is discussed.


Section 3.9 - Parameterized classes

Prior to the definition of the ref_succ class is the sentence, "The
type parameter in the declaration may actually be constrained in the
body of the class definition."  Is this referring to the "x_init + 1"
statement?  If I understand correctly, this constrains x_init to the
integer type because + operates on integers.  Because of this, is

  class ['a] ref_succ (x_init:'a) =  (etc...)

necessary?  Can't one write

  class ref_succ x_init =  (etc...)

and the type of x_init will be determined by the body?


Section 3.12 - Cloning objects

The text reads, "The library function Oo.copy makes a shallow copy
of an object. That is, it returns an object that is equal to the
previous one. The instance variables have been copied but their
contents are shared."  Should the last sentence read, "The instance
variables have been copied but their contents are _not_ shared"?

Later in the section, the text reads, "Two objects are equal if and
only if they are physically equal. In particular, an object and its
copy are not equal."  However, in the previous excerpt, it states
that Oo.copy "returns an object that is equal to the previous one."
Does "equal" in the latter sense refer to how we as humans think of
things as equal (i.e. they contain the same values, therefore they
are equal) but not "equal" in the sense of the OCaml language (i.e.
a equality test will fail)?


That's it for me.  Thank you so much for your time.

Ish


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Confusion about chapter 3 in the OCaml manual

[Jacques Garrigue]

From: "Ishmael Yavitz" <ishmaelyavitz@hotmail.com>

> COMMENTS ON CHAPTER 3 OF THE OBJECTIVE CAML MANUAL
> (10 DEC 2001 RELEASE)
> 
> Section 3.1 - Classes and Objects
> 
> After the definition of the class point and an instantiation of the
> class, the text reads, " [point] stands for the object type
> <get_x : int; move : int -> unit>, listing the methods of class point
> along with their types."  Should this be taken to mean that an object
> type is defined by its methods, and not at all by its member
> variables?

Yes. You cannot access member variables from outside an object.

> Are classes with exactly the same methods then somehow equivalent?

Yes: their objects are equivalent. But their class types are not
equivalent: you can do different things using inheritance.

> Why is the type of the class "point" printed as in the above excerpt,
> when after entering the definition the interpreter returns
> 
> class point :
> object method get_x : int method move : int -> unit
> val mutable x : int end
> 
> It seems to me that the above suggests that the member variables (x in
> this case) are a part of the type of the class, not just the methods,
> as was suggested above.  Is this correct?

Yes. Class type and object type are different.
An object type contains only the public methods of the corresponding
class type.

> Section 3.5 - Private methods
> 
> Below the definition of the restricted_point class and some examples
> is the sentence, "Private methods are inherited (they are by default
> visible in subclasses), unless they are hidden by signature matching,
> as described below."  Where is the signature matching described?  If
> I understand correctly, (I did execute the code) the rest of the
> examples in the section describe how to make a previously private
> method public in a child class, not how to hide it.  How can one hide
> a method so it can't become public in a child class?

# class c = object (self)
    val x = 1
    method m = self#n
    method private n = x
  end;;
class c : object method m : int method private n : int val x : int end
# class d : object method m : int end = c;;
class d : object method m : int end

This way method n is hidden in class d, but you can still call it via
method m.

> In the first definition of point_again appears the line
> 
> object (self : < move : _; ..> )
> 
> but what exactly does this line mean?

It forces the move method to be public, using hidden behaviour of type
inference. But this looks more confusing than useful... It is probably
more readable to use the other way.

> So in this context, the "problem" is how to make a method become
> public, not how to hide a method?  Also, what does "heavier" mean in
> this context?

It refers to the "method move = super#move" line, by opposition to the
constraint on the type of self in the previous version.
 
> Another question: the class definition the above text refers to is
> 
> class point_again x =
>   object (self : < move : _; ..> )
>     inherit restricted_point x as super
>     method move = super#move
>   end;;

Here the annotation on self is superfluous. This is an error of the
documentation.

> Section 3.6 - Class interfaces
> 
> After the definition of the class restricted_point_type appears the
> text, "Both instance variables and concrete private methods can be
> hidden by a class type constraint. Public and virtual methods,
> however, cannot."  I don't understand what this means.  Is this
> referring to the hiding of methods that was mentioned briefly in
> the previous section?

Yes, see my example above.

> Section 3.7 - Inheritance
> 
> Near the end of the section appears the text, "Methods need not be
> declared previously, as shown by the example..."  I don't understand
> this sentence.  Does this mean that after the following instruction:
> 
> #let set_x p = p#set_x;;
> 
> set_x can be applied to any object that has a set_x method?

Yes. Isn't it cool ? And all this type safe !

> Section 3.8 - Multiple inheritance
> 
> It is my understanding that multiple inheritance refers to a class
> that inherits directly from more than one class.  (For example, class
> colored_line inherits from both the class color and the class line.)
> Some languages do not permit this because of problems - for example,
> when both parents have a method or member variable of the same name,
> which one should be used in the child?  What does "multiple
> inheritance" refer to in the manual text?

In case of name conflict, OCaml uses the code from the last inherit
statement. Note that all identically named methods should have same
types, since all calls will be redirected to the last one.

> At the end of this section is the sentence, "A private method that has
> been hidden in the parent class is no longer visible, and is thus not
> overridden." Is this the same "hiding" that was discussed previously?

Yes: if a private method is hidden, then it will not be merged with
identically named methods when inherited. This is an interesting case
were hiding changes the semantics.

> Section 3.9 - Parameterized classes
> 
> Prior to the definition of the ref_succ class is the sentence, "The
> type parameter in the declaration may actually be constrained in the
> body of the class definition."  Is this referring to the "x_init + 1"
> statement?  If I understand correctly, this constrains x_init to the
> integer type because + operates on integers.  Because of this, is
> 
>   class ['a] ref_succ (x_init:'a) =  (etc...)
> 
> necessary?  Can't one write
> 
>   class ref_succ x_init =  (etc...)
> 
> and the type of x_init will be determined by the body?

Yes, of course, but the intent of this example was to show that a
parameter may in fact be forced to be a specific type. This is not
really useful in practice (you would expect this type to have some
free variables), but is just there for demonstration.

> Section 3.12 - Cloning objects
> 
> The text reads, "The library function Oo.copy makes a shallow copy
> of an object. That is, it returns an object that is equal to the
> previous one. The instance variables have been copied but their
> contents are shared."  Should the last sentence read, "The instance
> variables have been copied but their contents are _not_ shared"?

No, the text is correct. Think of an array of arrays. If you copy the
array, you will get a new array containing the same arrays, so that
modifications on the arrays will be shared between the two copies.

Of course, this only matters if you put mutable data structures inside
your fields, otherwise you will not see the sharing.

> Later in the section, the text reads, "Two objects are equal if and
> only if they are physically equal. In particular, an object and its
> copy are not equal."  However, in the previous excerpt, it states
> that Oo.copy "returns an object that is equal to the previous one."

Interesting: the previous excerpt was plainly wrong (only true in very
old versions of ocaml). An object is not equal to its copy, for both
logical (=) and physical (==) equality. Only their fields are equal.


It seems that this chapters needs a bit of re-writing.
Hope this helps,

Jacques Garrigue
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr