Re: [PEPr] Comment on Console::Console_CommandLine

Hey Travis, thanks for your answers, In svn, I commited Renderer and Outputter changes, they now use an interface and have been renamed to Console_CommandLine_{Renderer,Outputter}_Default... Please take a look at: http://console-commandline.googlecode.com/svn/trunk/ I'll update the proposal with the changes made soon. Now for my answers: > I agree - the naming of this is tricky Console_ComandLineParser > might work. Another option is moving the command line parsing code > into a Console_CommandLine_Parser class and have it return a > Console_CommandLine object instead of a Console_CommandLine_Result > object. Actually, I would prefer that naming syntax as it ties the > name of the package and its object to a Domain Model rather than a > portion of the implementation. not sure about this, actually I think that "Console_CommandLine_Result" is clearer. Furthermore, considering it all, I don't think that the name of the package is misleading: a "command line" is "$ <someprogram> -v arg1 arg2" and after all Console_CommandLine purpose is to parse this stuff... Maybe it would help to know what other people think about the package name ? > I would move that to the Outputter I think. Only console output will > care on character size, and not all developers are really going to > care about console size. If you're outputting a help for use on the > web, or in a DocBook, the whitespace becomes less of an issue. At > any rate, the CommandLine_Outputter object will just need a straight > string to output, then it can wrap it as necessary. hmm anyway, you won't be able to use Console_CommandLine for the web or for DocBook directly since it's a command line parser (it parses $_SERVER['argv']...), but it could be possible to re-use xml definitions to build a web interface of course. That said, you're right, the wrapping stuff could be moved to the outputter, fair enough, I'll look at this. > One solution would be to add a Console_CommandLine_Registry object > that has all of the default values preset on it (see PHPT_Registry @ > https://svn.phpt.info/Core/trunk/src/PHPT/Registry.php for a > Singleton Registry). That moves the coupling of other objects to the > Registry instead of Console_CommandLine. On the Registry, add a > public static $default_values array to hold the default values, then > when the Registry is instantiated it can set all values to those to > start with. In this case, a registry is a bit overkill I think :) These protected static properties should not be modified (I don't see the use case for this) and they exist just to be kept grouped somewhere, to keep me happy when maintaining code. BTW, I'll need suggestions on how to handle i18n messages, I'd like to have Console_CommandLine strings "translatables", but I'm not sure what's the best way to do this (xml or plaintext or php language files ?, a php array to pass to the class... ?) maybe this has been done in existing PEAR packages ? > I prefer having an exception thrown for everything as it allows it to > be caught without some sort of error handling hack put in place. Again, I'm not sure about this: programming/api_usage errors should trigger errors IMHO. If you do an error while creating your parser object, the program won't be able to run properly, so there's no need for recovering the error by using a try/catch, It's something I learned from python: it's better to keep it simple when it comes to exception handling. Furthermore, you force the programmer to write two different exception handling code, one for his/her errors and another for the user errors, because the user certainly doesn't want to know about the programmer errors, the program should *just work*. Finally I've looked at some existing PEAR packages and they seem to do the same: they trigger_error when it comes to programming errors. Maybe someone can tell us more, but I think the "all is an Exception" is not a good practice. -- David JL <izimobil@gmail.com>