Objects: contributing the dynamicprops and hgsetget classes

Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Objects: contributing the dynamicprops and hgsetget classes

FARHI Emmanuel

Hello,

I've written two superclasses for Octave, that emulate the

  • dynamicprops (add new properties to classes)
  • hgsetget (allow to use set/get on classes)

as found in Matlab. My classes are not made Abstract, but this could be done, to avoid direct instantiation.

The repositories are on Github:

I'd be happy to see them in Octave, to improve the compatibility on class definitions. The hgsetget has been renamed as the matlab.mixin.SetGet class since Matlab 2013, but the hgsetget name is still supported to date.

Thanks, Emmanuel.

-- 
FARHI Emmanuel - Tel: +33 (1) 69 35 96 04 Room A1.0.34
Experimental Division / Data Reduction and Analysis Group
Synchrotron Soleil - Saint-Aubin BP 48 - 91192 GIF/YVETTE CEDEX
http://www.synchrotron-soleil.fr
Reply | Threaded
Open this post in threaded view
|

Re: Objects: contributing the dynamicprops and hgsetget classes

apjanke-floss


On 10/30/19 10:06 AM, FARHI Emmanuel wrote:

> Hello,
>
> I've written two superclasses for Octave, that emulate the
>
>   * *dynamicprops* (add new properties to classes)
>   * *hgsetget* (allow to use set/get on classes)
>
> as found in Matlab. My classes are not made Abstract, but this could be
> done, to avoid direct instantiation.
>
> The repositories are on Github:
>
>   * https://github.com/farhi/octave-dynamicprops
>   * https://github.com/farhi/octave-hgsetget
>
> I'd be happy to see them in Octave, to improve the compatibility on
> class definitions. The /hgsetget/ has been renamed as the
> /matlab.mixin.SetGet/ class since Matlab 2013, but the /hgsetget/ name
> is still supported to date.
>
> Thanks, Emmanuel.

Hi Emmanuel,

These are just my thoughts as an Octave contributor; if any of the core
maintainers have thoughts too, you should probably defer to them.

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 I were you, I'd reformat your packages so they could be installed
with the `pkg install <url>` command, which would get you a better user
base potential, and then advertise them on the octave-help mailing list.
(Plus then, other packages could declare dependencies on yours, and
you'd make your way into the dependency web.) After that, if you get
some users, apply to Octave Forge to make it an "external"/community
package, and after that see about donating them to core Octave itself.

Unfortunately, I can't find a good document on "how to make a good
Octave pkg-conformant package". That's a bummer. Can any of the core
Octave developers help us out here? Seems like this is a document that
ought to exist.

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Objects: contributing the dynamicprops and hgsetget classes

Nir Krakauer-3


Unfortunately, I can't find a good document on "how to make a good
Octave pkg-conformant package". That's a bummer. Can any of the core
Octave developers help us out here? Seems like this is a document that
ought to exist.


General info on package format is in the Manual [1] with some additional tips in the Forge site [2]. There's an example package that's supposed to demonstrate how to deploy different capabilities [3].



Reply | Threaded
Open this post in threaded view
|

Re: Objects: contributing the dynamicprops and hgsetget classes

mmuetzel
In reply to this post by FARHI Emmanuel
Am 30. Oktober 2019 um 15:06 Uhr schrieb "FARHI Emmanuel":

> Hello,
> I've written two superclasses for Octave, that emulate the
>
> dynamicprops (add new properties to classes)
> hgsetget (allow to use set/get on classes)
> as found in Matlab. My classes are not made Abstract, but this could be done, to avoid direct instantiation.
> The repositories are on Github:
>
> https://github.com/farhi/octave-dynamicprops
> https://github.com/farhi/octave-hgsetget
> I'd be happy to see them in Octave, to improve the compatibility on class definitions. The hgsetget has been renamed as the matlab.mixin.SetGet class since Matlab 2013, but the hgsetget name is still supported to date.

Thank you for showing your willingness to contribute to Octave.

I haven't tested your classes. But cross-reading the code, the implementation looks promising.
Some initial feedback: Please, read [1] and adapt to the Octave style guide. Also adding some BISTs, demos and a texinfo style documentation would help. Maybe have a look at containers.Map [2] as some kind of a template.
Ideally, open a new report on the patch tracker [3] and provide a patch to Octave's development sources.
You are always welcome to ask for more details or feedback here on the mailing list or on the patch tracker.

There are only a few maintainers, so it might take some time until someone will be able to review. But it will definitely make it more likely that someone picks up your contribution if you follow those guidelines.

Markus

[1]: https://wiki.octave.org/Octave_style_guide
[2]: http://hg.savannah.gnu.org/hgweb/octave/file/tip/scripts/%2Bcontainers/Map.m
[3]: https://savannah.gnu.org/patch/?group=octave


Reply | Threaded
Open this post in threaded view
|

RE:Objects: contributing the dynamicprops and hgsetget classes

FARHI Emmanuel
In reply to this post by Nir Krakauer-3
Hi,

I've started to reformat my classdef contributions as regular octave-forge packages.
Unfortunately, the included Texinfo help is not parsed correctly in classdef, as mentioned in https://savannah.gnu.org/bugs/?48041. So manually generated doc files should probably be added.

So, as of today, it is possible to install both superclasses with 'pkg install' from the releases in my github repos. The next step is to link it to the official octave-forge, but I do not know yet how to do that.

Cheers to all, Emmanuel.

De : Nir Krakauer [[hidden email]]
Envoyé : samedi 2 novembre 2019 15:11
À : Andrew Janke
Cc : FARHI Emmanuel; Octave Maintainers
Objet : Re: Objects: contributing the dynamicprops and hgsetget classes



Unfortunately, I can't find a good document on "how to make a good
Octave pkg-conformant package". That's a bummer. Can any of the core
Octave developers help us out here? Seems like this is a document that
ought to exist.


General info on package format is in the Manual [1] with some additional tips in the Forge site [2]. There's an example package that's supposed to demonstrate how to deploy different capabilities [3].



Reply | Threaded
Open this post in threaded view
|

Re: Objects: contributing the dynamicprops and hgsetget classes

Carnë Draug
In reply to this post by apjanke-floss
On Sat, 2 Nov 2019 at 04:16, Andrew Janke <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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 [[hidden email]]
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Objects: contributing the dynamicprops and hgsetget classes

Carnë Draug
On Sun, 10 Nov 2019 at 14:09, FARHI Emmanuel
<[hidden email]> wrote:

>
> 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)

Please open a patch report for each one of those at:

  https://savannah.gnu.org/patch/?func=additem&group=octave

Note that hgsetget is deprecated in Matlab, so not sure if it makes
sense to add it to Octave to remove it soon.

> 2- where should it go in the repo hierarchy ? (e.g. scripts/lang as
> in Matlab ?)

I would imagine it should go into miscellaneous.  There is no
scripts/lang in Octave.

~ carandraug