Re: Implementation of importdata belonging to Octave Core or Octave-Forge?

[c.]

On 21 Oct 2012, at 09:24, address@hidden wrote:

> Maybe csv2cell, cell2csv and its siblings. Those are very useful 
> functions because they allow for mixed type (numeric and text) I/O 
> from/to csv.
> IMO the spreadsheet stuff had better wait until Java support is 
> integrated in core (some time, some day).
> 
>> In that way we re-activate the OctaveForge -->  core flow (and we
>> make a better Octave!)
> 
> What do other devs think?

I totally agree with JuanPi myselef, and actually I think his view was also
agreed upon by all at the latest OctConf.

>> Also, if there is a desired to add more functions to core the first
>> place to look is to globaly used, well tested packages in Forge! :D
> 
> Oh I agree. Core and OF could have a tighter relationship.

Yes, but it is important that the relationship remains one-way.

I don't think it makes any sense to have functions in core 
that depend on Forge packages.

If function "foo" in Octave-core depends on function "bar" in package 
"foobar" I would regard that as a bug that can be fixed in two ways:

1) If "foo" is of general interest and deserves staying in core, move "bar" to 
core.

2) If "foo" is related to some specific task that is taken care of by
functions in Forge, then move "foo" to the package "foobar" or
some other Forge package depending on "foobar".

> But (given the average number of active maintainers over a longer 
> period) there's also something to say for keeping core Octave compact 
> and well-maintained, and leaving specialized functions in OF.

I totally subscribe to this point of view and I think the guidelines above are 
in the same direction as this comment.

So what shall we do with importdata, should we take optin 1) or 2) or is there 
a 3)?

> Philip

c.