octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pkg.m planned refactoring [was: Help trying to merge my changes to c


From: Carlo De Falco
Subject: Re: pkg.m planned refactoring [was: Help trying to merge my changes to current default]
Date: Fri, 23 Mar 2018 09:32:51 +0000


> On 22 Mar 2018, at 13:55, Juan Pablo Carbajal <address@hidden> 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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]