Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Confusion about chapter 3 in the OCaml manual
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Ishmael Yavitz <ishmaelyavitz@h...>
Subject: [Caml-list] Confusion about chapter 3 in the OCaml manual
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.

(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

Don't the

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


    method move = super#move

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

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.


Get your FREE download of MSN Explorer at

Bug reports:  FAQ:
To unsubscribe, mail  Archives: