On 9 December 2012 23:14, Daniel J Sebald<address@hidden> wrote:
On 12/09/2012 03:59 PM, Carnė Draug wrote:
On 9 December 2012 20:49, Juan Pablo Carbajal<address@hidden>
wrote:
I totally disagree with that policy. We have to provide a good way to
search for functions, not to stick t the braindead way of classifying
functions in matlab.
On 9 December 2012 21:17, Daniel J Sebald<address@hidden> wrote:
I agree that organizing packages on the basis of Matlab's organization
isn't
necessary.
Indirectly, this is the same policy/organization that decides if a
function should go into an Octave Forge package or into Octave core.
I'm not understanding. What is the same policy? How so indirectly?
We have been following Mathworks' organization of functions not only
to decide in which package a function should go, but also if it should
go into core or into forge.
This means that if someone submits a new function that does not exist
in a matlab toolbox, the decision lies in how "general" or useful that
function is, and how committed that person is to maintain the
submitted code. However, if the function already exists in a matlab
toolbox we don't care about this anymore, it just goes to a forge
package. Even though a function that mathworks bothered to implement,
even if only in one of their toolboxes, is likely to be something more
people use. And if it was written by a forge developer, then they are
also some of the most committed to maintain the code. This only makes
sense because we follow matlab organization.
Now, Octave can't become a collection of all Octave code that is out
there, but if we decide to say "screw matlab, their organization
doesn't make sense. This function should go into some more appropriate
package" then we can also start saying "screw matlab, their
organization doesn't make sense. This function is to broad and should
should go into core, not into a package".
And of course, broad, general use, more useful, etc can be relative.
But so can be the area or field of a specific function.