[Caml-list] Deep copy

[Caml-list] Deep copy

[zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN]

Hi all,

I'm writting a program that manipulates a graph structure and I need to make
deep copies of some of the graph nodes. The function Oo.copy donesn't perform
a deep copy and I haven't found any other that could make it.

Actually, the nodes of my graph are specified using a lot inheritance, and if
I want to write specific "copy" methods for them, I will need to disperse the
clonning actions downto the leaf of my inheritance tree.

So I'd like to know is there is a clean way to make a deep copy of any object.

Thank you.

--
Michaël Marchegay, Stagiaire France Telecom R&D du 11/02/2002 au 26/07/2002
Sous la responsabilité d'Olivier Dubuisson
DTL/TAL - 22307 Lannion Cedex - France
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Ken Wakita]

How about the following?

Marshal.from_string (Marshal.to_string [Marshal.Closures] obj) 0

Ken Wakita

> From: "zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN"
> <michael.marchegay@rd.francetelecom.com>
> Date: Mon, 15 Jul 2002 12:06:58 +0200
> To: <caml-list@inria.fr>
> Subject: [Caml-list] Deep copy
> 
> Hi all,
> 
> I'm writting a program that manipulates a graph structure and I need to make
> deep copies of some of the graph nodes. The function Oo.copy donesn't perform
> a deep copy and I haven't found any other that could make it.
> 
> Actually, the nodes of my graph are specified using a lot inheritance, and if
> I want to write specific "copy" methods for them, I will need to disperse the
> clonning actions downto the leaf of my inheritance tree.
> 
> So I'd like to know is there is a clean way to make a deep copy of any object.
> 
> Thank you.
> 
> --
> Michaël Marchegay, Stagiaire France Telecom R&D du 11/02/2002 au 26/07/2002
> Sous la responsabilité d'Olivier Dubuisson
> DTL/TAL - 22307 Lannion Cedex - France
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Eray Ozkural]

On Monday 15 July 2002 16:42, Ken Wakita wrote:
> How about the following?
>
> Marshal.from_string (Marshal.to_string [Marshal.Closures] obj) 0
>

That's guaranteed to be slow isn't it? :)

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Ken Wakita]

Depends on how large graphs are and how often this facility is used in the
application.  Marshal.to_string tries to compress the structure into a
binary string.  Storage allocation, compression, and decompression are
potential overhead.  If you need faster version, you can make your own.  Try
look at byterun/extern.c.  It's an over-night job, if you are lucky.

Ken Wakita

> From: Eray Ozkural <erayo@cs.bilkent.edu.tr>
> Organization: Bilkent University CS Dept.
> Date: Mon, 15 Jul 2002 17:43:52 +0300
> To: Ken Wakita <wakita@is.titech.ac.jp>, zze-MARCHEGAY Michael stagiaire
> FTRD/DTL/LAN <michael.marchegay@rd.francetelecom.com>, caml-list
> <caml-list@inria.fr>
> Subject: Re: [Caml-list] Deep copy
> 
> On Monday 15 July 2002 16:42, Ken Wakita wrote:
>> How about the following?
>> 
>> Marshal.from_string (Marshal.to_string [Marshal.Closures] obj) 0
>> 
> 
> That's guaranteed to be slow isn't it? :)
> 
> -- 
> Eray Ozkural <erayo@cs.bilkent.edu.tr>
> Comp. Sci. Dept., Bilkent University, Ankara
> www: http://www.cs.bilkent.edu.tr/~erayo
> GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Ken Wakita]

I apology that I sent a silly code fragment last night.  I included two
mistakes.

Small one: the order of arguments to to_string was wrong.  it should be:

    Marshal.from_string (Marshal.to_string obj [Marshal.Closures]) 0

Worse one: it does not work for OO features (sigh).

Sorry for disturbance.

Ken

> From: Ken Wakita <wakita@is.titech.ac.jp>
> Date: Mon, 15 Jul 2002 22:42:49 +0900
> To: zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN
> <michael.marchegay@rd.francetelecom.com>, caml-list <caml-list@inria.fr>
> Subject: Re: [Caml-list] Deep copy
> 
> 
> How about the following?
> 
> Marshal.from_string (Marshal.to_string [Marshal.Closures] obj) 0
> 
> Ken Wakita
> 
>> From: "zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN"
>> <michael.marchegay@rd.francetelecom.com>
>> Date: Mon, 15 Jul 2002 12:06:58 +0200
>> To: <caml-list@inria.fr>
>> Subject: [Caml-list] Deep copy
>> 
>> Hi all,
>> 
>> I'm writting a program that manipulates a graph structure and I need to make
>> deep copies of some of the graph nodes. The function Oo.copy donesn't perform
>> a deep copy and I haven't found any other that could make it.
>> 
>> Actually, the nodes of my graph are specified using a lot inheritance, and if
>> I want to write specific "copy" methods for them, I will need to disperse the
>> clonning actions downto the leaf of my inheritance tree.
>> 
>> So I'd like to know is there is a clean way to make a deep copy of any
>> object.
>> 
>> Thank you.
>> 
>> --
>> Michaël Marchegay, Stagiaire France Telecom R&D du 11/02/2002 au 26/07/2002
>> Sous la responsabilité d'Olivier Dubuisson
>> DTL/TAL - 22307 Lannion Cedex - France
>> -------------------
>> To unsubscribe, mail caml-list-request@inria.fr Archives:
>> http://caml.inria.fr
>> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
>> http://caml.inria.fr/FAQ/
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Eray Ozkural]

On Monday 15 July 2002 13:06, zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN 
wrote:
> Hi all,
>
> I'm writting a program that manipulates a graph structure and I need to
> make deep copies of some of the graph nodes. The function Oo.copy donesn't
> perform a deep copy and I haven't found any other that could make it.

You mean something like creating a new object on the heap and copying over the 
contents of an existing object.

If this were C++ all you had to do would be invoking the copy constructor
 Node* x = new Node(old_node);

>From the documentation OO.copy does look like a deep copy operation:

val copy : < .. > -> < .. >
Oo.copy o returns a copy of object o, that is a fresh object with the same 
methods and instance variables as o

Curious,
 
-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Nicolas Cannasse]

> > I'm writting a program that manipulates a graph structure and I need to
> > make deep copies of some of the graph nodes. The function Oo.copy
donesn't
> > perform a deep copy and I haven't found any other that could make it.
>
> You mean something like creating a new object on the heap and copying over
the
> contents of an existing object.
>
> If this were C++ all you had to do would be invoking the copy constructor
>  Node* x = new Node(old_node);

Errr....
You're supposing here that either the copy constructor is implemented by the
class writer or then that you're using the default copy constructor which
only copy fields, and then do not perform any deep-recursion... It's even
worst because pointers are duplicated so you can get very-unsafe behavior...

> From the documentation OO.copy does look like a deep copy operation:
>
> val copy : < .. > -> < .. >
> Oo.copy o returns a copy of object o, that is a fresh object with the same
> methods and instance variables as o

The "copy" notion is ambiguous, especially when you have mutable fields.
Does the modification of such a field on a copy of an object do influence
the original object ? Or is copy only the image of an object at a given time
? And what if the object manipulate opened streams ?
Not so easy to resolve... I would recommand then to write a copy operator
"by hand".

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Eray Ozkural]

On Monday 15 July 2002 18:27, Nicolas Cannasse wrote:
>
> Errr....
> You're supposing here that either the copy constructor is implemented by
> the class writer or then that you're using the default copy constructor
> which only copy fields, and then do not perform any deep-recursion... It's
> even worst because pointers are duplicated so you can get very-unsafe
> behavior...
>

You're right. A default deep copy probably wouldn't work for most applications 
:) That's why you usually have to write your own copy constructor in C++. 
Still it is a convenient thing to have a "clone" function that can do it. 
Even in the presence of recursive definitions and such it ought to be 
possible.

This could be useful when one has objects for data structures... Though it 
could be said it is a better style to use recursive types and the module 
system when you are doing complex data structures, cloning looks like one of 
those handy features that you expect from an object system.

> The "copy" notion is ambiguous, especially when you have mutable fields.
> Does the modification of such a field on a copy of an object do influence
> the original object ? Or is copy only the image of an object at a given
> time ? And what if the object manipulate opened streams ?
> Not so easy to resolve... I would recommand then to write a copy operator
> "by hand".

I think Michael made that clear. Oo.copy does a shallow copy, it provides that 
all members of the new object will have physical equivalence to the given 
object. Therefore, modifying a mutable field on a copy should influence the 
original one.

The best kludge here would be to write an external function for all types that 
need the deep copy as you suggest. He could write his own copy function 
instead of Oo.copy

Writing a copy method inside each class would look worse :)

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[sebastien FURIC]

zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN a écrit :
> 
> Hi all,
> 
> I'm writting a program that manipulates a graph structure and I need to make
> deep copies of some of the graph nodes. The function Oo.copy donesn't perform
> a deep copy and I haven't found any other that could make it.
> 
> Actually, the nodes of my graph are specified using a lot inheritance, and if
> I want to write specific "copy" methods for them, I will need to disperse the
> clonning actions downto the leaf of my inheritance tree.

 If your "copy" methods are really specific, I don't see any way of
doing that without reimplementing "copy" in each class you want to
change objects' behavior of... This is object-orientation.

 Or maybe I don't understand your problem.

 Why "functional copy" (i.e. {< ... >}) don't solve your problem ?

 Cheers,

 Sébastien.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] Deep copy

[zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN]

> De : Eray Ozkural [mailto:erayo@cs.bilkent.edu.tr]
> Envoyé : lundi 15 juillet 2002 17:03
> 
> 
> On Monday 15 July 2002 13:06, zze-MARCHEGAY Michael stagiaire 
> FTRD/DTL/LAN 
> wrote:
> > Hi all,
> >
> > I'm writting a program that manipulates a graph structure 
> and I need to
> > make deep copies of some of the graph nodes. The function 
> Oo.copy donesn't
> > perform a deep copy and I haven't found any other that 
> could make it.
> 
> You mean something like creating a new object on the heap and 
> copying over the 
> contents of an existing object.
> 
> If this were C++ all you had to do would be invoking the copy 
> constructor
>  Node* x = new Node(old_node);
> 
> From the documentation OO.copy does look like a deep copy operation:
> 
> val copy : < .. > -> < .. >
> Oo.copy o returns a copy of object o, that is a fresh object 
> with the same 
> methods and instance variables as o

In fact, if an object 'a' contains an attribute 'b' that is another 
object, Oo.copy on 'a' gives a copy of 'a' in which the attribute
'b' is **physically** equal to the copied attribute from 'a'.

Example:
class a = 
  object 
    val mutable b = new b
    method get_b = b
  end
and b = 
  object
    val mutable c = "1"
    method set_c x =  c <- x
    method print_c = print_string ("c=" ^ c ^ "\n")  
  end

let aa = new a
let aa' = Oo.copy aa

let _ = 
  aa#get_b#set_c "3";
  aa#get_b#print_c;
  aa'#get_b#print_c

gives:
c=3
c=3

whereas a deep copy would give:
c=3
c=1

> 
> Curious,
>  
> -- 
> Eray Ozkural <erayo@cs.bilkent.edu.tr>
> Comp. Sci. Dept., Bilkent University, Ankara
> www: http://www.cs.bilkent.edu.tr/~erayo
> GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 
> 7C07 AE16 874D 539C
> 
> 
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Eray Ozkural]

An equivalent of C++'s copy constructor would be required. Can this be done 
without going "inside" the ocaml system? :)

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Alessandro Baretta]

Eray Ozkural wrote:
 > An equivalent of C++'s copy constructor would be
 > required. Can this be done without going "inside" the
 > ocaml system? :)

Please, leave copy constructors alone. They are among the
most hideous enemies of an OO programmer. The copy 
constructor always has very delicate interactions with 
assignment and function invocation, and since one often 
needs to redefine the copy constructor, for example to get 
deep copies as opposed to shallow copies, it is a serious 
source of bugs.

O'Caml has a neat OO system, with a single constructor and 
no destructors. I don't think it needs to borrow many ideas 
from C++.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Alessandro Baretta]

zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN wrote:
> In fact, if an object 'a' contains an attribute 'b' that is another 
> object, Oo.copy on 'a' gives a copy of 'a' in which the attribute
> 'b' is **physically** equal to the copied attribute from 'a'.

I agree so far. But did you actually test the code below? I 
have reason to believe you are mistaken in believing that 
mutable fields are shared between Oo.copied objects, in such 
a way that assignment to such a field in one object will 
result in a modification in the value of the same field in 
all copies. I would consider such a behavior a major design 
flaw in the language.

The following toplevel session proves my point:

# class a i = object val mutable c = i method m = c <- c + 1 
; print_string ((string_of_int c) ^ " ") end;;
class a : int -> object method m : unit val mutable c : int end
# let a1 = new a 0;;
val a1 : a = <obj>
# let a2 = Oo.copy a1;;
val a2 : a = <obj>
# for i = 1 to 10 do a1 # m done;;
1 2 3 4 5 6 7 8 9 10 - : unit = ()
# for i = 1 to 15 do a2 # m done;;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 - : unit = ()
# for i = 11 to 15 do a1 # m done;;
11 12 13 14 15 - : unit = ()

Alex

> Example:
> class a = 
>   object 
>     val mutable b = new b
>     method get_b = b
>   end
> and b = 
>   object
>     val mutable c = "1"
>     method set_c x =  c <- x
>     method print_c = print_string ("c=" ^ c ^ "\n")  
>   end
> 
> let aa = new a
> let aa' = Oo.copy aa
> 
> let _ = 
>   aa#get_b#set_c "3";
>   aa#get_b#print_c;
>   aa'#get_b#print_c
> 
> gives:
> c=3
> c=3
> 
> whereas a deep copy would give:
> c=3
> c=1

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[John Prevost]

>>>>> "ab" == Alessandro Baretta <alex@baretta.com> writes:

    ab> I agree so far. But did you actually test the code below? I
    ab> have reason to believe you are mistaken in believing that
    ab> mutable fields are shared between Oo.copied objects, in such a
    ab> way that assignment to such a field in one object will result
    ab> in a modification in the value of the same field in all
    ab> copies. I would consider such a behavior a major design flaw
    ab> in the language.

The code he gave is correct.  The problem arises not when the object
itself contains a mutable field, but when one of its fields contains a
mutable value.  (An object with a mutable field, a string, an array, a
record with a mutable field, a ref, etc.)

# class a = object
    val s = "     "
    method get x = s.[x]
    method set x c = s.[x] <- c
  end;;
class a :
  object
    method get : int -> char
    method set : int -> char -> unit
    val s : string
  end
# let x = new a;;
val x : a = <obj>
# x #get 0;;
- : char = ' '
# x #set 0 'a';;
- : unit = ()
# x #get 0;;
- : char = 'a'
# let y = Oo.copy x;;
val y : a = <obj>
# y #get 0;;
- : char = 'a'
# y #set 0 'b';;
- : unit = ()
# y #get 0;;
- : char = 'b'
# x #get 0;;
- : char = 'b'

As far as I can tell, the poster to whom you are responding was simply
pointing this out: if a field contains a mutable value (whether the
field itself is mutable or not), the contents of that field are
copied, which results in physical equality of the field values in
those cases where physical identity is important.  He doesn't appear
to have claimed that the copied fields themselves have physical
equality.

John.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[Alessandro Baretta]

John Prevost wrote:
>>>>>>"ab" == Alessandro Baretta <alex@baretta.com> writes:
>>>>>
> 
>     ab> I agree so far. But did you actually test the code below? I
>     ab> have reason to believe you are mistaken in believing that
>     ab> mutable fields are shared between Oo.copied objects, in such a
>     ab> way that assignment to such a field in one object will result
>     ab> in a modification in the value of the same field in all
>     ab> copies. I would consider such a behavior a major design flaw
>     ab> in the language.
> 
> The code he gave is correct.  The problem arises not when the object
> itself contains a mutable field, but when one of its fields contains a
> mutable value.  (An object with a mutable field, a string, an array, a
> record with a mutable field, a ref, etc.)
...
> As far as I can tell, the poster to whom you are responding was simply
> pointing this out: if a field contains a mutable value (whether the
> field itself is mutable or not), the contents of that field are
> copied, which results in physical equality of the field values in
> those cases where physical identity is important.  He doesn't appear
> to have claimed that the copied fields themselves have physical
> equality.

Ah, yes! My mistake. I misread the previous post. I'm sorry 
for that. I'm coding too much and sleeping too little.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Deep copy

[John Prevost]

>>>>> "ab" == Alessandro Baretta <alex@baretta.com> writes:

    {... asked about deep copy ...}

In any case, here's a simple example of the appropriate way to
implement deep copy:

(* just for reference *)
class type deep_copyable =
  object ('s)
    method deep_copy : 's
  end

class point =
  object
    val mutable x = 0
    val mutable y = 0
    method get_x = x
    method get_y = y
    method set_x x' = x <- x'
    method set_y y' = y <- y'
    method deep_copy = {< >}    (* no mutable slots *)
  end

class rect =
  object
    val mutable ul = new point
    val mutable lr = new point
    method get_ul = ul
    method get_lr = lr
    method set_ul ul' = ul <- ul'
    method set_lr lr' = lr <- lr'
    method deep_copy = {< ul = ul #deep_copy; lr = lr #deep_copy >}
  end

Note that this strategy works even if class rect doesn't have mutable
slots--since it uses the special cloning with override construct.
There is some awkwardness with inheritance in that an inheriting class
really needs to have mutable values to work well.  You either have to
do:

class tri =
  object
    inherit rect as super_r
    val mutable ur = new point
    method get_ur = ur
    method set_ur ur' = ur <- ur'
    method deep_copy =
      let c = super_r #deep_copy in begin
        c #set_ur (ur #deep_copy);
        c
      end
  end

(* or *)

class alt_tri =
  object
    inherit rect
    val mutable ur = new point
    method get_ur = ur
    method set_ur ur' = ur <- ur'
    method deep_copy =
        {< ul = ul #deep_copy; lr = lr #deep_copy; ur = ur #deep_copy >}
  end

The first version has a problem if ur does not have a public "set_"
method--since the copy is a different object, you cannot manipulate
its slots directly.  The good thing about it is that it doesn't need
to list all of the inherited slots directly, since the inherited
deep_copy method takes care of that.  This problem will show up if you
want to copy a field which is private state (not settable from
outside.)

The second version must list all of the slots to copy directly.  It
doesn't require that the slot to be modified has a public set method.
But: if the superclass changes to have more slots that must be
duplicated, the subclass must also change.  If it does not, the
internal invariants of the class inherited from may fail, since two
objects now share a resource.

A final version uses composition instead of inheritance (which can
often be a good thing) to handle this:

class comp_tri =
  object
    val comp_r = new rect
    val mutable ur = new point
    method get_ul = comp_r #get_ul
    method set_ul = comp_r #set_ul
    method get_lr = comp_r #get_lr
    method set_lr = comp_r #set_lr
    method get_ur = ur
    method set_ur ur' = ur <- ur'
    method deep_copy = {< comp_r = comp_r #deep_copy; ur = ur #deep_copy >}
  end

The composition version requires that each method you want to
replicate be replicated by hand.  The drawback is that if the
contained class which you're delegating for changes, you may not have
all the methods which the composed class has.  The good thing about
this approach is that if this causes real problems, the type system
should pick up on it.  (i.e. calls to those methods on your class will
fail.)  And--there is no chance that the internal invariants of the
composed class will be broken: you use only the published interface to
interact with it.  The drawback is that you cannot override behavior
of the composed object's calls to itself.


In summary:

 * The mechanism used in "tri" is the most common case when classes do
   not have internal (hidden) state that must be duplicated.  The
   problem arises when the *inheriting class* has such state, not when
   the *inherited* class has such state.  It allows overriding of self
   method calls.

* The mechanism used in "alt_tri" handles internal state in a way
  which may break, but allows overriding of self method calls.  The
  breakage may be difficult to detect.

* The method used in comp_tri handles internal state in a safe
  way--invariants are never broken--but does not allow overriding of
  self method calls, since no subclassing is actually occuring.  This
  mechanism is most appropriate in cases where the interface is only
  extended, and no old methods are to be overridden.


I hope this rundown is useful to you.  Although copying of state is
particularly troublesome, these three patterns (call superclass do
extra work, replace superclass, composition) also arise in other sorts
of methods, with similar drawbacks and advantages.  In the end, it all
comes down to the following observation: subclassing may lead to
useful sharing of behavior, but it breaks modularity--whenever a
superclass changes, all subclasses must be examined to be sure their
behavior remains correct.


John.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners