OOP and load/save

[Robert T. Short]

The following message is really intended to get some help addressing the
problem of load/save using legacy MATLAB objects.

In order to do this, I will need to describe some structure.

First, legacy MATLAB objects are built by making a directory beginning
with @, so that the class Foo would be contained in a directory @Foo.
This directory contains a bunch of m-files called methods.  One of the
methods, the class constructor, must be called Foo.m.  A sample Foo.m
might be

function [f] = Foo()

 f.dataelement = somevalue;      % First create a struct that has the
desired class data members.
 .
 .
 .
 f = class(f, 'Foo');                      % A call to "class" takes
the struct "f" and returns an object.

end


The object returned by a class constructor is a struct with some extra
baggage.  The struct has the data elements you put there to start with,
but has some different behaviors, e.g. you can't directly access the
struct members except from a class method (an m-file inside the @Foo
directory).


A call to Foo() will create an object:

> f = Foo();

Now, suppose we have another object called "Bar", living in directory
@Bar and with constructor.

function [f] = Bar()

 f.dataelement = somevalue;
 .
 .
 .
 f = class(f, 'Bar');

end

We want to create a class FooBar, modeled as follows


 Foo
   ^
    |
 FooBar  <>-- Bar

That is, FooBar will be derived from Foo, but will contain an element of
class type Bar.  In the directory @FooBar, create the file FooBar.m


function [f] = FooBar()

 f.Bar = Bar();                        %  Create an element in the
class called Bar that is an object of type Bar.
 fu  = Foo();                            % Create an object of type Foo
 f = class(f,'FooBar',fu);          % create an object of type FooBar
derived from Foo.

end


The class function will take the struct it was given, create an object
of type FooBar with those struct elements.  The class function also
creates a struct member called "Foo" that will hold the data for the
object created from Foo.m.

Now it gets interesting.  In this case there are two elements of the
class struct that are also objects, and the name of the struct element
is also the name of the class.  There is no way to tell directly from
the struct whether the object is derived from the struct element or
aggregated from the struct element.  In the implementation I created in
octave, I created a list of strings that contain a list of the parents.
Thus, I don't have any problem differentiating between the two situations.

All fine so far, but when the save file is created it really just dumps
the struct - that is the parent list is lost.  So when I read the .mat
file back, I can't tell whether I have an aggregation or an
inheritance.  Bummer.

So, I have two solutions.  The first one is easy.  MATLAB could probably
read and reconstruct such objects ok, but octave couldn't read such
files created by MATLAB properly.

-----
First way.

Suppose I just write a character array with struct element name
__parent_list__ or some such that contains the parents.  Of course this
would clobber any actual struct element by that name, etc.  It might not
be legal to have a struct name like that in MATLAB.

----
Second way.  This is probably the more sensible way, and is almost
certainly the way MATLAB does it.

When I read an object out of the .mat file, I need to force the
constructor m-file for that object to be parsed and executed so that I
have the struct built and ready, although what I really get is the
parent list.  I then replace the individual elements that I read out of
the file into the object's struct.  There has to be some checking to
make sure that the struct is valid, etc., but that, I think, is pretty
straightforward.

I think this works, yes?  I have no idea how to cause the constructor to
be parsed and executed, but I am sure I can figure this out.

----

Bob
--
Robert T. Short
PhaseLocked Systems