Re: classdef is pretty good now (inputParser implemented in core). What now? How to document classdef classes?

[John W. Eaton]

On 08/22/2014 02:27 AM, PhilipNienhuis wrote:

> What is needed / how difficult would it be to get I/O to .mat files for
> classdef objects?

Do you mean Matlab style .mat files?  What version of them?

I don't know how hard it would be.  Probably similar to what is needed 
for the legacy style classes, except that more information must be 
stored because classdef classes store more information about the objects 
that they represent.

In any case, I think now might be a good time to decide whether we 
should continue to support all of the various forms of data files that 
load/save handles or deprecate and eventually drop them in favor of only 
supporting the MAT style that uses HDF5, possibly with extensions.

The formats we currently support includes Octave text, Octave binary, 
Octave HDF5, MATvN.  Dealing with all of them represents a pretty large 
maintenance burden for us. I don't count the ascii format here because 
that is just for saving numeric data without any header info, and the 
old MATv4 format won't change, so very little maintenance is required. 
But keeping all of them means that any time we want to add something 
like support for classdef objects, we have to update at least four 
different formats.  That's a lot of extra work.

Also, I don't think we really support the latest HDF5-based file format 
used by Matlab.  So maybe the best thing to do would be to add support 
for the latest HDF5-based Matlab format and only add classdef support 
for that format.  We could keep the others, but not extend them to 
classdef or any other new data types that we add and eventually phase 
them out except for reading old data files.

jwe