Re: OOP and load/save

[John W. Eaton]

On 24-Apr-2009, Judd Storrs wrote:

| > Something that I keep meaning to ask JWE is whether we should derive
| > octave_class from octave_struct.
| 
| I agree, but given all the work that has to go on inside the interpreter to
| get classes to work with the language--isn't the only thing that
| differentiates a class from a struct the class name?

It's fine with me to change things so octave_class is derived from
octave_struct.  I can't remember now why I didn't do it that way from
the beginning.  Maybe I just didn't think it would work, or maybe I
tried it and there was some problem.  I really don't remember.  But
it would probably be best to hold off on this change until we have
finished the changes for inheritance.

| That's what the m-file
| format suggests and that's why I proposed always reading objects from files
| as structs and asking the interpreter to convert them to classes.  But then I
| got the impression that John was saying that octave allows C++-based classes
| to not be based on struct representations?

In the olden days when Octave did not support Matlab-style objects,
you could only introduce new data types by using the same method as
used for Octave's built-in types.  You had to define a class like
octave_struct or octave_foo.  You can do this dynamically, using a
.oct file.  Since Octave doesn't know anything about these types until
they are loaded, we had to have a way to ask these kinds of
user-defined data types to save and load themselves.  That's the main
reason behind the design of the load/save code in Octave.  Saving is
easy, because you already have an object of the appropriate type.  For
loading, the idea is that you get the type information first, then
construct a default object of the given type, then ask it to finish
loading itself.  Once you've constructed the object and asked it to
load itself, there is no convenient way to generate a different kind
of object, at least with the current design.  Changing the way this
works will likely break compatibility with previous versions of
Octave.  It's not a big priority for me.  But maybe we can come up
with some kind of workaround just for the class->struct conversion
that happens when Matlab attempts to load a class and fails to find a
compatible object or constructor for it.

jwe