-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexandru Stanoi wrote: > Frederik Holljen wrote: >>> > Design goals >>> > ============ >>> > >>> > The workflow of a creating a SystemProcess object applying certain >>> arguments as >>> > well as options to it and finally spawning the process should be >>> intuitive as >>> > possible. The best way to achieve such an intuitive API would be to >>> design it >>> > having the fluent interface pattern in mind. The used interface should >>> look >>> > something like this:: >>> > >>> > new ezcSystemProcess( 'echo' )->argument( 'foo' )->execute(); >>> >>> Method chaining can not be done with "new classname", so it has to be: >>> >>> $p = new ezcSystemProcess( 'echo' ); >>> $p->argument( 'foo' )->execute(); >> I don't see why the fluent interface pattern makes this more >> intuitive. I'd say it makes it less intuitive as a command is really >> not complicated at all and the fluent interface pattern is to make a >> complicated API more intuitive to use. >> >> Consider: >> cmd = array( 'program_name', 'arg1', 'arg2', 'arg3', 'arg4', 'arg5', >> 'arg6', 'arg7' ) >> pOpbject = ezcSystemProcess::execute( cmd ) >> >> vs >> $p = new ezcSystemProcess( 'program_name' ); >> $p->argument( 'arg1' )->argument( 'arg2' )->argument( 'arg3' >> )->argument( 'arg4' )->argument( 'arg5' )->argument( 'arg6' >> )->argument( 'arg7' )->execute(); >> >> Which one is easier to read and less hassle to write? Another >> advantage of the top one is that you can easily alter one parameter >> and then run the command again. >> >> I'd take a look at the python subprocess module. It's an elegant >> solution which should provide some good ideas. > > How about keeping the same syntax as the Database component? To execute > for example this command: > > $ pear install -a ezc/eZComponents > > you can write: > > <?php > $p = new ezcSystemProcess(); > $p->prepare( 'pear :command :arg1 :component' ); > $p->bindValue( ':command', 'install' ); > $p->bindValue( ':arg1', '-a' ); > $p->bindValue( ':component', 'ezc/eZComponents' ); > $p->execute(); > ?> > > to reuse the same prepared command for '$ pear ugrade ezc/eZComponents': > > <?php > // same $p as before > $p->bindValue( ':command', 'upgrade' ); > $p->bindValue( ':arg1', '' ); > $p->execute(); > ?>
I like the idea to be consistent with the sql abstraction. But if this is done it should be used exactly like the sql abstraction is. This would make your example look like this: <?php $command = 'install'; $argument = '-a'; $p = new ezcSystemProcess( 'pear' ); $p->argument( $p->bindParam( $command ) ); $p->argument( $p->bindParam( $argument ) ); $p->argument( $p->bindValue( 'ezc/eZComponents' ) ) // I think this should be possible as well, as it is also supported by // the database component // $p->argument( 'ezc/eZComponents' ) $p->execute(); $command = 'upgrade'; $argument = ''; $p->execute(); ?> I think a fluent interface should be used as done in the sql abstraction. The user is therefore not forced to use it, but may if it fits his statements. I am not sure about the correct usage of setting $argument or :arg1 in your example to an empty string. You did this to kind of remove the parameter. I don't think this is the way to go here. As setting the parameter to '' should just create an empty parameter which is still existent in the build command line. Otherwise tools like rename for example could not be used to delete parts of a filename as therefore a real empty parameter has to be set. Using the proposed way it would also be easily possible to provide methods like "bindPathValue" which could take care of cross platform path escaping. best regards Jakob - -- Jakob Westhoff (GPG 0xCBF7FC6A) http://westhoffswelt.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJJibYzAAoJEE0XwzzL9/xqjMQIAI5Xr5ia/PDnOc2dsmRgU5Bz lRzZABM+pJZd4LN2KVo9mir9m24ToVFI1CBTAGlaRDqH5qPAFo65bOp7mkQUfg58 LnSRwWGopCY2Zt7ZP22AWg6hxej24rbEkoMVW/dq9WbUTNueOYn19savLSIu14i6 z05pHLgV6dfkNkZWnrtoTatUeZJJ/jjdBb+VjeM5hAQEOraakIftjuOWbY+YGgNN BqNjbMpNjcgCJILCk4OLg58hgwy4QENb4Jk12LNUVFVfLC5CIvoV/sJ3l91/5ScB S0cYLe9kTbigb1Ig+fXAmaH0z8137iBcKX3VNtJzgbewr2zNm2zq1PigD3Gmdvc= =Uoam -----END PGP SIGNATURE----- -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
