[Octave-task-tracker] [task #15419] Implement Table I/O

[Andrew Janke]

Follow-up Comment #3, task #15419 (project octave):

Sounds like a good initial plan.

1. I think we should expose all the cell data types, not just the ones we care
about right now. That way a client can decide whether they're important and
what, if anything, to do about them.

2. & 3. Yep.

4. Instead of using the options struct, maybe we could add an additional input
and output argument to xls2oct()/ods2oct()/etc. Make the signature like this:


[ rawarr, xls, rstatus, extra_arrs ] = xls2oct (xls, wsh, range, options,
extra_data_items)


Where extra_data_items is a cellstr vector naming what additional data items
should be pulled out (e.g. "datatype" for the raw cell datatype name, "format"
for the display format that's needed for detecting Excel dates, "cellstyle"
for font/bold/italic/border information, "formula" to unconditionally grab
underlying formulas, maybe "type" for a higher-level cell type detected by
io's heuristics), and extra_arrs is a cell vector containing the corresponding
arrays of retrieved data. extra_arrs is the same size as extra_data_items, and
extra_arrs{i} contains the data item identified by extra_data_items{i}.

Selecting what items of data are to be returned is maybe important/common
enough to justify its own input argument, instead of being stuck in one of the
options. On the other hand, the options form might be easier to read, since it
wouldn't be just a positional parameter in a getting-long function signature.
So maybe it should be a new argout, but a new "extra_items" option instead of
a brand new argin.

BTW 2. If we get this working for table in Tablicious, we can totally port it
over to the dataframe package. They're similar data structures and will have
the same needs from the io package, except that dataframe doesn't know about
@datetime or @categorical.

BTW 3. I didn't know about importdata(). I'll have a look at it.

I'm pretty familiar with Apache POI, and could handle updating the POI
interface to do this, once we decide on a signature and how we're going to
represent cell types etc at the M-code level.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/task/?15419>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/