David Coallier [2008-01-06 20:12 UTC] Hrm. Couldn't you wrap that up in a simple class ?
Things like getVersion would be much cleaner (maintainable) if you'd save it in a const.
To be honest I find that to be a very dirty way of doing it. You could simply make a static call passing the options to your methods that are going to be deciding what to do.
Restructuring your code will also allow people to make frontends and use the code as they want around their code.
So resume:
- Wrap all your functions into a class (Make it instantiable)
- your pearize command file should simply be passing the Console options to the cli constructor or such
- By doing this you'll clean the whole bazongle that is at the bottom of the file (procedural part with direct switch, etc)
- I would add a display method that you would invoke when you want to echo some data that way, one could overload the display method to any type of display (xml, html, text, etc) (IE: $obj->display("Total: 30kb");)
Christian Weiske [2008-01-07 07:01 UTC] I'd like to see that as a plugin to the pear installer, not as a standalone package.
Michel Corne [2008-01-07 10:24 UTC] Interesting. Fine as standalone command, but could definitely be plugged into the pear command.
I ran it on packages I did install but got a "package xyz not found". I have not investigated why. Note though that I am running XP and that my pear install is not the default PHP directory. However, the -V and -help options seem run fine.
The file should be made into a class and the last 200 lines or so could be broken into manageable functions.
I did not see any unit tests which I guess is okay at this point in the proposal process.
Chuck Burgess [2008-01-09 21:50 UTC] I'm thinking this does make sense as a standalone package, in that I can see other uses of it besides being used by the installer. One use in particular I see is having PEAR_Config be capable of showing this extra info in its output.
|
