On 04/02/2009, Tobias Schlitt <[email protected]> wrote: > Hi Fred, > > btw. nice to see you being so active here. :) Hehe, you know me. Once I feel strongly about something I'm not letting it go that easily. Something caught my eye and now I have to follow up on it :)
> > On 02/04/2009 05:08 PM Frederik Holljen wrote: > > On 04/02/2009, Jakob Westhoff <[email protected]> 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. The shell API (e.g writing commands) is written like that because of the limitations of writing everything on a single line. Most people hate the command line because it is hard to use. This is the reason why we have GUI's. Even though we are programmers and most people that would use this component has some knowledge of the shell; is this something we want to imitate? To sum it up: Design patterns are used to do one or both of two things: 1. Solve a problem that otherwise can't be solved 2. Make what you're making more intuitive or easier to use We're clearly not doing 1. The arguments I've seen for 2 are: - Shorter to write (questionable if you ask me) - looks more like the shell (not what you want in my opinion) - similar to db component (I don't see why we should complicate this simple matter and make an analogy to a component just because we can) However, I realize that I'm the only one arguing for a simple approach so I'll rest my case after this closing argument :) > 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. Strictly speaking this is not a task of the system command component. The functionality could also be implemented as a static method. Cheers, Frederik -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
