Re: very small packages - merge into general/miscelleneous or move into core

[Carnë Draug]

There's a lot of things on those emails and breaking it apart to do a
point by point reply is too confusing so I'll just write a single long
reply.

Functions are grouped in packages based on a common subject. When a
subject is really small, it doesn't make sense to have a separate
package. That's why we have an image and signal package but not a
package for morphology, image transformation, colour conversion, image
io, etc... There is no well defined line to when a package has become
too small but strings and struct have definitely crossed it.

I actually don't much see the point of a general and miscellaneous
package. If things are specialized, they go into a package with a
theme, if they're "general" and useful, they could go into core, if
they are not that useful then they go in miscellaneous because we
don't have other place for them. Let us remember that many of the
packages names were inherited from the same structure found in Octave
core which may no longer make sense since Octave Forge was split into
individual packages. And I think it was suggested before to merge them
together (maybe on IRC).

Carlo, you may now be against physical_constants() having been merged
into the miscellaneous package, but originally you were in favour
because it reduced the number of packages [1]. You're correct that
someone that needs physical_constants() is probably not looking for
game of life or a sudoku solver but it also works the other way
around. Someone looking for game of life and sudoku won't be looking
for physical constants. As Octave Forge is now, the solution will not
be to split them into individual packages.

About seqreverse, it makes sense in bioinfo because it's targeted at
reversing biological sequences. While it may reverse any string for
Matlab compatibility, I wouldn't be surprised if it refused to reverse
a string with characters that have no biological interpretation. Also,
there's alternatives to strings for bio sequences and I'd expect
seqreverse to handle them too.

About inputParser, I placed it into general because I thought that's
where it would be if it was part of Octave core, next to nargchk,
narginchk, nargoutchk, and validateattributes. Once it can be made
really Matlab compatible, it will be moved into Octave core.

Finally, my suggestions are in no way about moving to a monolithic
release of Octave Forge, it's about cleaning up old stuff that no
longer makes sense and are only wasting time. In some cases, that
means merging packages together, but mostly I think is about removing
functions. On merging stuff together: it's much simpler to fix things
progressively as new Octave versions come out than to fix them 7 years
later when they're broken all over. And whatever time that takes, it's
still less than the time it takes to prepare multiple package
releases. On removing functions: to deprecate stuff because better
alternatives are implemented elsewhere is standard and good practice.
We do not need to include everything ever done before, tarballs of the
old stuff are still freely available. We have kept the old stuff for
long enough.

Maybe what we really need is more maintainers but we don't and this is
the change that reduces the amount of maintenance.

So back, to strings [2] and struct [3]. What to do about their functions?

There's functions such as getfields [4] and setfields [5] (note the
plural against the versions that exist in core, they do different
things) which I can see a use. Could a behaviour like that be
implemented in core? Using a cell array of fieldnames as second input
for getfield() and setfield()?

And there's functions such as tars [6] which simply create a structure
from a list of key names, whose values are the same as the key name.
Do we really need something like that?

Carnë

[1] 
http://octave.1599824.n4.nabble.com/no-more-combinatorics-and-physical-constants-package-tp4645305p4645354.html
[2] http://octave.sourceforge.net/strings/overview.html
[3] http://octave.sourceforge.net/struct/overview.html
[4] http://octave.sourceforge.net/struct/function/getfields.html
[5] http://octave.sourceforge.net/struct/function/setfields.html
[6] http://octave.sourceforge.net/struct/function/tars.html