Comment author: jpdeplaix

I agree, this would be useful.

Comment author: @garrigue

What you are asking for is not completely clear.

The simple one (and closest to functional update) would be to allow just to override methods externally.
I.e., you just build a new immediate object forwarding most calls to the original object, and redefining some methods (but not visible from the original ones). Actually this is just a kind of syntactic sugar, but requiring to know the type of the object.

Another meaning would be to copy the object, changing the method table.
Doable too, but rather different, as in this case the state is not shared.
Moreover this require that methods have exact types: this would be unsound if methods were allowed to have subtypes in subclasses (as per the Abadi-Cardelli book).

Finally you might want to update the method table of the current object. But in that case this is destructive update, not functional, and this would break completely the semantics.

Also, for soundness reasons, in none of this case you would be allowed to access value fields from newly defined methods (they do not appear in the object interface).

Comment author: tom.j.ridge

Without knowing much about objects, I believe I am asking for

"The simple one (and closest to functional update) would be to allow just to override methods externally."

But, the scenario I am in means that I don't know exactly which methods are available on the object (but I know one method that is - the method I want to override). This means that I can't just make a new object (with methods delegating to the old object except for the "updated" method).

I think this makes semantic sense, but I'm not sure.

Comment author: tom.j.ridge

Also, it would be super-useful if there was support for adding in new methods e.g.

{{ myobj with some_new_method=some_fun }}

if this makes sense.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Yes, the first semantics proposed by @garrigue seems like the way to go, and it sounds not too hard to implement. We haven't spent much effort lately improving the object system (which makes sense given how little it is used by most OCaml projects), but the feature still makes sense and we can easily see how it would be useful for some use-cases (both to override or to extend).

(This goes back to a more general discussion about whether we should have polymorphic records, or make objects easier to use as polymorphic records.)

I suppose that this means having polymorphic operations of the form:

update_m : (self:(< m : 'a; .. > as 'obj) -> 'a) -> 'obj -> 'obj

that actually update the virtual table.
With the current implementation, this seems relatively easy.
Still, this would not be as efficient as one could hope: one needs to replace all other methods by closures calling the same method on the original object.
The alternative semantics of making it behave like inheritance seems unsafe, at it would allow to change the behaviour of an internal method on a running object, with has security implications.

Adding a method would be harder, and cannot be done polymorphically (i.e. that would actually be type-directed syntactic sugar).

Just for fun here is an implementation of functional update.

diff --git a/stdlib/camlinternalOO.ml b/stdlib/camlinternalOO.ml
index 0188c148cd..a60d385c61 100644
--- a/stdlib/camlinternalOO.ml
+++ b/stdlib/camlinternalOO.ml
@@ -455,6 +455,33 @@ let lookup_tables root keys =
   | Empty ->
     build_path (Array.length keys - 1) keys root
 
+(**** method update ****)
+
+let redirect obj n = ret (fun _self -> sendself obj n)
+
+let copy_table (tbl : closure array) (obj : obj) (n : tag) (m : closure) =
+  let len : int = Obj.magic (Array.unsafe_get tbl 0) in
+  let tbl' = Array.make (len*2+2) (Obj.magic len) in
+  Array.unsafe_set tbl' 1 (Array.unsafe_get tbl 1);
+  for i = 1 to len do
+    let ofs = 2 * i in
+    let tag = Array.unsafe_get tbl (ofs+1) in
+    Array.unsafe_set tbl' (ofs+1) tag;
+    Array.unsafe_set tbl' ofs
+      (if Obj.repr tag == Obj.repr n then m else redirect obj ofs);
+  done;
+  tbl'
+
+let update_method (tag : [> ]) (obj : < .. > as 'a) (m : 'a -> Obj.t) : 'a =
+  if not (Obj.is_int (Obj.repr tag)) then invalid_arg "Oo.update_method";
+  let tag : tag = Obj.magic tag in
+  let obj = Obj.repr obj in
+  let mets : closure array = Obj.obj (Obj.field obj 0) in
+  let mets' = copy_table mets (Obj.obj obj) tag (ret (Obj.magic m)) in
+  let obj' = Obj.new_block Obj.object_tag 2 in
+  Obj.set_field obj' 0 (Obj.repr mets');
+  set_id (Obj.magic obj')
+
 (**** builtin methods ****)
 
 let get_const x = ret (fun _obj -> x)
diff --git a/stdlib/camlinternalOO.mli b/stdlib/camlinternalOO.mli
index b6ffc70d7f..d407bd215a 100644
--- a/stdlib/camlinternalOO.mli
+++ b/stdlib/camlinternalOO.mli
@@ -151,3 +151,12 @@ type stats =
     methods : int;
     inst_vars : int }
 val stats : unit -> stats
+
+(** {1 Method update} *)
+
+val update_method : [> ] -> (< .. > as 'a) -> ('a -> Obj.t) -> 'a
+
+(*
+let update_m (obj : < m : 'a ; .. >) (m : 'a) =
+  CamlinternalOO.update_method `m obj (fun _ -> Obj.repr m);;
+*)

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.