Hi Fred, btw. nice to see you being so active here. :)
On 02/04/2009 05:08 PM Frederik Holljen wrote: > On 04/02/2009, Jakob Westhoff <ja...@westhoffswelt.de> wrote: >> >> $p = new ezcSystemProcess( 'foobar' ); >> >> $p->workingDirectory( 'my/directory' ) >> >> ->environment( 'MY_ENVIRONMENT_VARIABLE', '42' ) >> >> ->environment( 'MY_OTHER_ENVIRONMENT_VARIABLE', '23' ) >> >> ->redirect( ezcSystemProcess::STDERR, ezcSystemProcess::STDOUT ) >> >> ->redirect( ezcSystemProcess::STDOUT, '/tmp/some/file') >> >> ->argument( '--first-option' ) >> >> ->argument( '--second-option-with-a-value' ) >> >> ->argument( $someValue ) >> >> ->pipe( $anotherSystemProcess ) >> >> ->execute(); >> > To me this reads like the environment has a redirect and that the >> > argument has a pipe etc. How is the above an improvement over the >> > classical interface: >> > $cmd = array( 'foobar', '--first-option', >> > '-second-option-with-a-value', $someValue ); >> > $p = new ezcSystemProcess(); >> > $p->workingDirectory = 'my/directory': >> > $p->addEnvironment( 'MY_ENVIRONMENT_VARIABLE', '42' ) >> > $p->addEnvironment( 'MY_OTHER_ENVIRONMENT_VARIABLE', '23' ) >> > $p->addRedirect( ezcSystemProcess::STDERR, ezcSystemProcess::STDOUT ) >> > $p->addRedirect( ezcSystemProcess::STDOUT, '/tmp/some/file') >> > $p->addPipe( $anotherSystemProcess ) >> > $p->execute( $cmd ); >> > >> > I think the latter more clearly describes the relation between the >> > options and the process. >> >> >> As far as I am concerned the fluent interface provides the way to create >> the command both ways. As you are not forced to use it, but have the >> chance to do so. > Yes, you have created a new way to create commands. But why? If it > doesn't provide any benefits over a normal interface what is the > point? I understand that you could use the fluent interface in the old > fashioned way also. But providing both just adds to the complexity > which makes it harder for people to use. I like the idea quite much to create a command as you would to it on the shell. With a fluent interface you always have the "problem" that you can do it both ways. At least, using the fluentness saves you some writing. >> Moreover it would be more consistent with the database >> abstraction component. > I don't see why you would want to be consistent with the database > abstraction component. It solves a completely different problem which > is a lot more complex. The two components are not related in any way. The SQL abstraction allows the creation of SQL commands, while the SystemProcess component allows the creation of shell commands. >> Thats a problem, which may be solved using the way I described in my >> other response to the idea of trying to reuse the database abstraction >> api. (Message-ID: <4989b633.6090...@westhoffswelt.de>) > I think that is to overcomplicate the solution quite drastically. Keep > it simple. I like the bindParam() solution here very much. It allows simple re-use of a once created statement with different values. This is another analogy to Database, where the same SQL statement can be used with different values. Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer t...@ez.no | eZ Systems AS | ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
