Re: regarding location of Matlab compatible polygon functions

[Juan Pablo Carbajal]

On Thu, Apr 7, 2016 at 11:29 PM, Carnë Draug <address@hidden> wrote:
> 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
>

The kind of "code breaking" you are pointing out here is of the kind

"
pkg load foo
"

to

"
pkg load foo
pkg load foo2
"

A horrible maintenance burden, definitely.

Also you are fixing a problem that it is not here and might ever come.
But since this is a matter of opinion and opinions are like butts...
do what ever you like.
It is always nice when working on geometry for differential equations
to load the mapping package, or the bioinformatics one...whatever,
yeah matlab is so logical.
The issue at the end is that we are working with a pretty primitive
way fo adding dependencies and we need to live with it.