Re: regarding GSoC 2016

[Philip Nienhuis]

Carnë Draug wrote:
> On 25 March 2016 at 07:57, PhilipNienhuis <address@hidden> wrote:
> > Carnë Draug wrote
> > > On 24 March 2016 at 12:05, Juan Pablo Carbajal &lt;
> >
> > > ajuanpi+dev@
> >
> > > &gt; wrote:
> > > > On Thu, Mar 24, 2016 at 12:54 PM, Neeraj Battan
> > > > &lt;
> >
> > > address@hidden
> >
> > > &gt; wrote:
> > > > > KaKila: Hi, thanks for having a look at my proposal. Can you please tell
> > > > > me which are the core projects?
> > > >
> > > > Everything that doesn't say "Package" is most likely core. Exception
> > > > is in "Infracstructure" the package manager.
> > > > With your profile I would also consider that project.
> > >
> > > The projects page should be cleared up then.  The logical operations on
> > > polygons are listed under missing core functions but would actually go
> > > into the mapping package.
> >
> > IMO they better fit in the geometry package. That already contains several
> > functions that operate on polygons.
> > Until recently oc_polybool() actually was in there, it was removed (as
> > JuanPi told me) because its author wanted so (it's now in octclip).
> >
> > Philip
>
> 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?

Philip