Re: classdef array objects

[Michael Goffioul]

On Thu, Sep 12, 2013 at 8:56 AM, John W. Eaton <address@hidden> wrote:

Michael, could you comment on the following?

I tried an example like

  classdef classarray
    properties
      x
    endproperties
    methods
      function obj = classarray (x, n)
        if (nargin == 0)
          disp ('constructing empty classarray object');
        else
          ## pre-allocate array of classarray objects
          obj(1, n) = classarray ();
          for i = 1:n
            obj(i).x = x;
          endfor
        endif
      endfunction
    endmethods
  endclassdef

and it failed to create an array object with an invalid object message
coming from mark_as_constructed.  I eventually realized that
cdef_object_array doesn't have the mark_as_constructed or
is_constructed methods.  When I added

  void mark_as_constructed (void) { }

  void mark_as_constructed (const cdef_class&) { }

  bool is_constructed (void) const { return true; }

to cdef_object_array, the above class appeared to work as I expected.
But I also noticed that scalar objects are considered constructed if
the list of constructors is empty.  I'm not sure whether there should
be a similar check for array objects or whether they should always be
considered constructed.

I think you're right. The above test case should have worked, and it used to work at some point. But I probably broke it when I extended the construction mechanism; hence the reason to have a good test suite. Because array classes are somehow implicit, I believe there's no need to check construction status and is_constructed should return true; the check for construction status is done at object level.

 

Finally, I see that cdef_object_array is implemented using
Array<cdef_object>.  Is it possible for each object in the array to
have a different set of properties?  If not, then maybe it would be
better for cdef_object_array to contain an octave_map and for
cdef_object to contain an octave_scalar_map for storing properties and
values.  That would avoid the duplication of storing the property
names N times.  Even with reference counting, it makes sense to me to
avoid the duplication.  If you agree, I can take a stab at changing the implementation to use octave_map and octave_scalar_map (Octave_map is currently used and is obsolete anyway).

I can see various potential problems with the suggested storage scheme:

1) how would you deal with handle objects, which can be shared between array and scalars? For instance:

    x = myHandleClass();

    y(2,2) = x;

    x.prop = 10;

    x.prop == y(2,2).prop;  % <== this should be true

2) how would you deal with dynamic properties?

3) it seems Matlab does not support polymorphism in array of handle class objects; however, some people tend to think it's a shame; maybe that would be a possible enhancement compared to Matlab

I admit that the current storage scheme is not the most efficient one, but I think that's the one that is the easiest to use and provide the most flexibility (because you really have "an array of object", such each individual object keeps its entire nature).

Michael.