657
edits
Code sprint: pkg.m: Difference between revisions
Jump to navigation
Jump to search
→Action functions
| (8 intermediate revisions by the same user not shown) | |||
| Line 9: | Line 9: | ||
* [[User:Carlo|cdf]] | * [[User:Carlo|cdf]] | ||
= | == Clone Carnë's repository == | ||
The code | https://bitbucket.org/carandraug/octave/changesets/tip/..bookmark%28%22pkg%22%29 | ||
= Parsing arguments passed to pkg = | |||
One of the most intimidating parts of pkg.m is the monstrous way the parsing of arguments is done. The current mayhem is probably due to the natural evolution of the code. | |||
the method use to parse the arguments is based on a flag system. | |||
We started cleaning up the parsing of options to give some structure and make pkg.m easy to extend in the future. For this we focus on encapsulation. | |||
== Definitions of actions, targets and modifiers == | |||
A typical call to pkg looks like | |||
pkg install -forge pkg1 pkg2 pkg3 -j4 | |||
We can identify three types of input arguments | |||
* Action: install | |||
* Modifiers: -forge, -j4 | |||
* Targets: pkg1, pkg2, pk3 | |||
So far we have defined them as follows | |||
* Action: The first input argument and can't start with a hyphen. | |||
* Modifier: Must start with a hyphen. | |||
* Target: Anything that is not an action nor a modifier | |||
== Dispatching == | |||
Each action has its own set of valid modifiers and behaves accordingly, that is the function ''pkg'' does not parse targets nor modifiers. Therefore the rôle of the main function ''pkg'' is to call the right action once general sanity checks have been performed. | |||
The particular implementation of this dispatch behavior was source of some discussion. | |||
* Using structure | |||
: One way of implementing the dispatch is using structures with fieldnames equal to the action and containing a function handle. [http://agora.octave.org/snippet/5UUz/ Here is an example]. | |||
: Some people do not like this because they consider it a weird use of a structure. | |||
* Using ''feval'' | |||
: Another way of doing it (and the implemented as of revision 2c16a852bae9 in carandraug's repository) is building a string of the function to call and use ''feval''. [http://agora.octave.org/snippet/ozym/ Here the example] | |||
* Using objects | |||
: Where we have an ''action'' class with fields valid_modifiers and method parse_modfiers. All ''_pkg'' actions inherit the general valid_modifiers and extend them with their own, as well as overloading the parser_modifier method. This gives the maximum flexibility, but since is too much of a change we haven't code it. | |||
== | === Action functions === | ||
The action functions have the suffix ''_pkg'' in their names. These functions should contain a cell of valid modifiers if they accept any. The function ''parse_target_modifier'' is called to check the validity of the modifiers and to separate them from targets. The cell of valid modifiers can contain regular expressions. This is required since we want to accept modifiers compatible with ''make'' flags (such as -jX for parallel compilation). | |||
=== No globals === | |||
We are trying to avoid global variables at all cost. Everytime a read-only value is needed in several functions, we create a helper function that returns the value. | |||
We have to see how we are going to solve the issue with actions like 'global_list' (deprecated, now called 'global_db') that can change the pointer to the file containing the package database. | |||
= | = Desired features = | ||
== Reverse autoload function == | == Reverse autoload function == | ||