Re: restructuring load-save

[David Bateman]

According to John W. Eaton <address@hidden> (on 11/20/03):
> On 20-Nov-2003, David Bateman <address@hidden> wrote:
> 
> What is the void* return type for the save/load functions for?  You
> don't seem to be using it here.

You're right it probably doesn't need a return type.

> | The the user type can overload the oct_* methods and setup the
> | have_oct_* functions appropriately. Similar things could also be done
> | for the Matlab and HDF file formats.
> 
> Yes, this is a start, but let's examine it a bit more. First, let's
> look at the save functions, because they are probably easier (we
> already have an object, so we know its type and can call a method for
> it).
> 
> If you are going to use virtual functions, then I think the default
> save functionality should be in the octave_base_value class in
> ov-base.{h,cc}.  Then you wouldn't need the have_*_save functions,
> because if a derived class did not provide it's own save or load
> function, you would get the default version in the octave_base_value
> class.  Since we would be splitting all the code in the current
> load-save functions up, I don't think there would be any old version
> of the code left, so we would probably just be left with a "unable to
> save objects of type XXX" error in the base code.  This is essentially
> trading a switch statement in the current code for virtual function
> dispatch, which is generally good, because extending it for new
> objects is potentially cleaner.

Ok, I saw this as a second step in the progression. The reason, I suggested
it the way I did was so that there was as little disturbance to the existing
code as possible at the outset and when the code was validated, then the
existing load/save functionality could also be moved to the new scheme.


> For the load functions, things are more difficult, because you don't
> know the type of the object until you read something from the file.
> But perhaps this is not too much of a problem because I think each
> file format includes some header information for each object that
> tells us what the type is, so we could do something like
> 
>   octave_name_and_value_struct
>   load_oct_binary_object (ostream& os, ...)
>   {
>     // get the name from the file along with a dummy object of the
>     // appropriate type (used for dispatching).
>     octave_name_and_value_struct tmp = read_object_info (os);
>     tmp.val.oct_load (os);
>     return tmp;
>   }
> 
> This function would be called repeatedly until an error occurs or we
> are out of values (signaled by returning an empty name and value
> struct?).  The information returned could be added to an octave_value
> struct array or inserted in the symbol table as needed.
> 
> Now, the only remaining problem is how to make load work for new
> types?  Obviously, the read_object_info function can't know everything
> about every type that might be added to Octave later, so it needs to
> get some information from the file and pass it to each of the possible
> octave_value subtypes in some reasonable order and allow them to
> decide whether they are the appropriate object type to handle the
> request.  Or, I suppose this could also be done with a lookup table
> that is filled in when the various types are installed in the
> interpreter.  We would also need some way of mapping MAT file type
> information to specific octave_value types.

I'd assumed that the type was already loaded. For ascii files the 
"# name:" field of the file would could the name of the type. A lookup
on the name in oct->type_name() would then find the corresponding type and
thus the appropriate load function. If the type isn't loaded an error would
occur. 

For the octave binary format the problem is different. At the moment there
is a char in the file that defines the type of the next variable

1 -> scalar
2 -> real matrix
3 -> complex scalar
4 -> coplex matrix
5 -> <nothing>
6 -> range
7 -> string

So to maintain compatiability what I'd propose is that 1-4,6,7 keep there
current definitions and type 5 becomes any type that uses the new scheme
to load data (user or existing methods). In this case the following data
is

int N;
char type_name[N];

We can then use the same scheme as for the ascii files to get the appropriate
load function.

I've not really looked at the matlab or hdf functions yet, but hope they 
might be dealt with in a similar manner.

Cheers
David

-- 
David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary