FYI: subasgn argument optimization

[John W. Eaton]

On 13-Aug-2009, Jaroslav Hajek wrote:

| 2. Since only one physical copy of the object always exists, an error
| inside subsasgn.m does not revoke changes that have already been made.
| It is solely the callee's responsibility not to leave the object in an
| invalid state. This may possibly alter the way code works (though well
| written code should probably work well). The internal variable
| optimize_subsasgn_calls is provided to switch off the optimization, if
| it causes problems. Another option is to declare different output and
| input arguments in the method.

This seems a bit problematic, since users have reason to expect that
an error during assignment doesn't alter existing data.

I'm a bit surprised that the situation is as bad as you describe, at
least for things like structs or cell arrays, which contain arrays of
octave_value objects, which are themselves reference counted objects.
So maybe we could do better and still preserve the current semantics
with regard to errors?

When you do something like

  s1 = struct (...);

you create a map with a collection of octave_value objects.  If
multiple copies of s1 are made, then the reference count for the
underlying octave_struct object is incremented.  Unsharing should
generate a separate copy the octave_struct object, but when copying
the elements in the map, we should only have to increment the count
for those objects.  What I would expect to happen is that we would
only copy the actual data for those objects if they were actually
changed.  If that's not happening and we are actually copying
everything at the first point of unsharing, then maybe that is
something that should be fixed?  Or maybe I'm misunderstanding
something and a complete copy of all elements in the map must happen
even when only a few elements are modified.

I probably won't be able to follow up on this discussion until
sometime Sunday at the earliest.

jwe