pkg.m planned refactoring [was: Help trying to merge my changes to current default]

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

pkg.m planned refactoring [was: Help trying to merge my changes to current default]

Juan Pablo Carbajal-2
Hi,

The plan is to use dispatching (just as was done in 2012) and let the
subfunctions do the parsing. Subfunctinos could use inputParser, no
problem at all.

The idea is that pkg.m becomes just a bookeeping function (very
simple!) and the work is passsed to the subfunctions.

I will define a standard procedure to parse options such that the
structure of the subfunctions is more or less always the same (ease
extending behavior, this was also done in 2012).

The only thing that is expect that wont be backwards compatible is the
future help system, which I will copy hg system, that is

pkg help

is the same as

help pkg

, but

pkg help install

(which currently doesn't exist) will provide detailed info about the command.
This is to also moves the writing of help to the subfunctions
(although I do not think it can be texinfo unless we make them
private). Being modular will simplify the maintenance.

I would try to keep backward compatibility as much as possible.

Cheers

Reply | Threaded
Open this post in threaded view
|

Re: pkg.m planned refactoring [was: Help trying to merge my changes to current default]

Carlo de Falco-2


> On 22 Mar 2018, at 13:55, Juan Pablo Carbajal <[hidden email]> wrote:
>
> Hi,
>
> The plan is to use dispatching (just as was done in 2012) and let the
> subfunctions do the parsing. Subfunctinos could use inputParser, no
> problem at all.
>
> The idea is that pkg.m becomes just a bookeeping function (very
> simple!) and the work is passsed to the subfunctions.
>
> I will define a standard procedure to parse options such that the
> structure of the subfunctions is more or less always the same (ease
> extending behavior, this was also done in 2012).
>
> The only thing that is expect that wont be backwards compatible is the
> future help system, which I will copy hg system, that is
>
> pkg help
>
> is the same as
>
> help pkg
>
> , but
>
> pkg help install
>
> (which currently doesn't exist) will provide detailed info about the command.
> This is to also moves the writing of help to the subfunctions
> (although I do not think it can be texinfo unless we make them
> private). Being modular will simplify the maintenance.
>
> I would try to keep backward compatibility as much as possible.
>
> Cheers
>

JPi,

I totally support this plan, actually I already agreed with this plan in 2012 it's such a pity it wasn't implemented earlier ...
I just noted that in 2012 InputParser was not available, now that it is I think it would worth considering whether it may help simplify things further.

c.