Re: regarding location of Matlab compatible polygon functions

[Carnë Draug]

On 25 March 2016 at 17:14, Philip Nienhuis <address@hidden> wrote:
> Carnë Draug wrote:
>> [...]
>> The functions proposed on the projects page are polybool, ispolycw,
>> poly2ccw,
>> poly2cw, poly2fv, polyjoin, and polysplit.  They all belong to the Matlab
>> mapping toolbox therefore would go into the Octave mapping package.
>
>     ? "...Matlab ... therefore..." ?
>
> That "therefore" comes a little quick for me.
>
> Until now I'm only sure that Octave strives to be Matlab-compatible in the
> sense of being able to run Matlab code. Good!
> But when did who decide that Octave should mimic Matlab beyond code
> compatibility and also copy less handy aspects? IOW, where is the basis for
> "... therefore..."?
>
> My motive is simply this:
> I find it much more natural to have functions sorted and divided into add-on
> packages according to what they do, rather then where they happen to be
> located in some commercial product that is required to keep a sometimes
> clumsy legacy around just because of its business model.
>
> New Octave users, not coming from Matlab, would expect functions operating
> on points, lines and polygons to be grouped together, and not scattered over
> separate "toolboxes" / add-on packages.
> Matlab users OTOH would quickly enough get used to "other" function
> locations. After all, Octave's "toolboxes" have no price tag hence no
> obstacle for installation AFAICS.
>
> Octave's mapping toolbox already has a (suggested) dependency on the
> geometry package for other functions than polygon operations.
>
> It's not that I'm pertinently against polygon operation functions in the
> mapping package. My motive is just what I wrote above.
>
> But I feel that the "decision", or lack of clear decision, about how far
> Octave should go to become a verbatim Matlab clone and thus also follow less
> logical/natural TMW decisions, is very implicitly made.  If the majority
> agrees, OK, then I'll shut up on this subject.
>
> Thoughts?
>

This is not a Matlab compatibility issue.  We are already not compatible
because we require the user to load the package.  Following the same structure
as Matlab when it comes for this packages means we have one less thing
to worry about.

Consider:

At the moment we have a geometry package.  The argument then goes that these
functions should go in geometry.  But if we didn't had geometry they would
happily go into mapping.  Let's imagine that in 1-2 years we create the
polygons package.  If the decision is that functions go in the most logical
package by name, we will want want to move those functions to polygons.
However, that would break code that was only loading geometry so we shouldn't
do it.  And then functions end up again in a non-optimally named package and
users will be confused (by the way, I disagree with the premise that new users
will be confused.  I think they are capable enough to find the right package
for a function).

Point is it can always be made a case for moving a function to a package with
a more specific name.

In another case, it can be argueed that while method "foo" is very useful in
field X, it is also useful in field Y.  Should we then move the function or
create a package only for a function that implements foo?  Will we end with
packages with a single function that are named isarray [1]?

---

Following this rule for this set of functions means one less thing to discuss.
And while Mathworks places a few functions in some really odd places, in
general they are logical.  At the same time, it also matches the place where
Matlab users would expect them.

Finally, I would like one day to have a set of packages be incorporated, as
packages, into Octave core (don't worry, there is no plan or work being done
in this direction -- I have only expressed my vision before).  I can imagine
that this vision will be easier if packages already follow the same guidelines
as core and have the functions in the right place.

Carnë

[1] https://www.npmjs.com/package/isarray