RE:Objects: contributing the dynamicprops and hgsetget classes

[FARHI Emmanuel]

Hello again,

I'm now willing to contribute my dynamicprops and hgsetget classes into the 
main Octave repo. Thanks to your advices I have added tests for each superclass 
(and tested the test works). I also updated the documentation but could not 
check it as 'help' does not seem to parse correctly texinfo headers with 
classdef.

So, I'd like to know if:
1- you agree in this, i.e. include dynamicprops and hgsetget as default octave 
packages (not octave-forge)
2- where should it go in the repo hierarchy ? (e.g. scripts/lang as in Matlab ?)

The two git repos are:
* https://github.com/farhi/octave-hgsetget
* https://github.com/farhi/octave-dynamicprops

May thanks for your input and advices.

Emmanuel.
________________________________________
De : Carnë Draug [address@hidden]
Envoyé : lundi 4 novembre 2019 03:22
À : Andrew Janke
Cc : FARHI Emmanuel; octave-maintainers
Objet : Re: Objects: contributing the dynamicprops and hgsetget classes

On Sat, 2 Nov 2019 at 04:16, Andrew Janke <address@hidden> wrote:
> [...]
> IMHO, the best way to get Octave code used by other users and then
> considered for core Octave is to make it available as a `pkg`
> distribution and then get in to Octave Forge. That makes it easy for
> users to find and install, and easy for other developers to test and
> build against.
> [...]

If the code in question implements something that is in Matlab core
and aims to be in Octave core too, I would recommend against this
approach.

The whole thing of having the code being tested as a package by the
community and later integrated in core never worked.  Better to aim
getting it into core from the start following core guidelines with a
comprehensive test suite.

Having it as a package also adds trouble to other packages that depend
on it once the code moves into core. Suppose function X is in package
foo but also in Octave core since version 7.  Octave's pkg does not
parse 'foo | octave >= 7' so you just add dependency on 'foo' but then
that gives warnings about shadowing core functions.  This gets worse
if the behaviour changed when moved to core (which is what happened
with inputParser).

This can all be avoided by aiming to get it into core.  I will guess
that it will get as much, if not more, people trying the code from
core development sources as if it tries as a package.  And once it
goes in core, it will be much more useful because users will not have
to go look for it.

~ carandraug