octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: classdef is pretty good now (inputParser implemented in core). What


From: Philip Nienhuis
Subject: Re: classdef is pretty good now (inputParser implemented in core). What now? How to document classdef classes?
Date: Fri, 22 Aug 2014 10:11:40 -0700 (PDT)

John W. Eaton wrote
> 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?

Good counter-question...


> 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.

That last suggestion would be the way to go I think.

(OT: I was asking because of a fairly large Matlab-based groundwater
modeling "toolbox" (code.google.com/p/mflab) made by a colleague of me that
used to work quite well with Octave, save for making movies. I was working
on getframe() stuff at that moment, the main missing video package item. 
However, some two years ago the complexity of it all grew over my
colleague's head and he switched to classdef (and that indeed simplified a
lot and opened up lots of new possibilities; much like Carnë described). 
I tried a few methods and they seem to work quite well; the big stumbling
block however is data I/O to/from .mat files.)

I had a brief look at matio (matio.sf.net) but there's little documentation
that matches my limited C++ proficiency. But maybe some stuff from matio can
be reused?

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/classdef-is-pretty-good-now-inputParser-implemented-in-core-What-now-How-to-document-classdef-classe-tp4666168p4666189.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]