Re: OOP and load/save

[Robert T. Short]

John W. Eaton wrote:
> On 23-Apr-2009, Judd Storrs wrote:
>
> | I don't know anything about the interpreter's internals, but it occurs to me
> | that another approach would be to always read in objects from files as
> | structs always and then attempt to do whatever class(obj,name) does. That
> | way if the class() call fails, the struct is already there?
>
> Doing that requires special knowledge about the way an octave_class
> object is defined and breaks the model of having the object load
> itself.  At the point where enough information has been read from the
> file to know that there is a problem, an octave_class object has
> already been constructed, not an octave_map (struct) object.  Yes, we
> could have a special case for class objects, but I don't think that's
> a good solution.  We can probably do better than that, but as I said,
> I think it will require some fairly substantial changes.  Doing it
> cleanly and consistently for all objects may require breaking backward
> compatibility for objects defined in C++ classes.  Not all of these
> are part of Octave itself (for example, the fixed class in Octave
> Forge).
>
> jwe
>
>
>   
Agreed.

John, let me make a proposal.  I think I can do a fairly quick fix that 
is ALMOST correct.  That way, folks (like me) can use the OOP facilities 
without worrying about long-term breakage.  Then I (or you or whoever) 
can take the time to really think about a correct implementation.

Here is my quick fix.  Some of what follows might be a little weak since 
I am still sitting in a meeting and don't have the code in front of me.  
But here we go anyway.



Suppose that I read the .mat file without concerning myself about the 
parent structure.  This involves simply creating an octave_class, 
setting the class name, and then creating a octave_map, I think 
(actually, I recall Cells being used, but I think we can still do this).

Then I can walk through the elements in the map.  IF the map elements 
are objects AND the object's class name is the same as the name of the 
struct field, just assume that I have a derived class.  Add it to the 
parent list for the class.  This has to recurse of course for multiple 
levels of inheritance.

So here is why I think this is crude but acceptable.  The biggest 
difference between a derived object and simple aggregation is that a 
derived object is able to access the parent's methods.  As an example, 
consider a method in the @Foo directory

function fout = fooMethod(fin)

 fout = some operation that operates on the structure elements of fin.

end

Also suppose we have a method in the @Bar directory

function fout = barMethod(fin)

 fout = some operation that operates on the structure elements of fin.

end


If I create FooBar object

> fubar = FooBar()

then I can do things like

> fubar = fooMethod(fubar)

but I can't do things like

> fubar = barMethod(fubar).

However, as long as I do it inside a class method, I can use both 
aggregated and parent classes in the same way

function someMethod(fin)

  fin.Foo = fooMethod(fin.Foo)
  fin.Bar = barMethod(fin.Bar)

end

Now, if I convert Bar from an aggregation to a parent, what happens?  I 
am now able to do

> fubar = barMethod(fubar)

and it will work.  However, I will not have EVER used that feature since 
it will only work after loading it from a file.

So, this is probably fairly easy, it will work, it will let me do my 
real job, and then I can move forward on a good solution.

Comments?  Am I all wet?

Bob