Re: [PEPr] Comment on Console::Console_CommandLine

Howdy... On Nov 20, 2007, at 8:24 AM, David JL wrote:

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.

Looks excellent.

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 ?

Yeah - two people does not a consensus make :-) In reading your response, I do want to clarify what I was intending. In the naming I suggested, Console_CommandLine is an object representation of "$ <someprogram> -v arg1 arg2". It becomes a Domain Model at that point. The Console_CommandLine_Parser is a Factory to parse a raw string representing a command line into the representation of it.

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.

Was a bad example on my part :-)

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.

I'll defer to other's opinion here. -T