Re: [PEPr] Comment on Tools and Utilities::ScriptReorganizer

>> Say I write a new strategy that >> renames variable to shorter names (blabla => a, foobar => b...). Now I >> may >> want to apply this strategy, but leave the formatting of the code >> unchanged >> (because I want to check everything is OK, I want to compare old to new >> code >> or whatever). I also may want to apply this strategy and the Route >> strategy, >> or this one and the Quiet one, or this one and the Pack one. >> This could be done by having a constructor that lets me create a >> RenameVariables strategy with another strategy (new RenameVariables(new >> Quiet) for example). > > I think that we are running in circles. With the design proposed this can > be > achieved without any hassles: > > $library = new ScriptReorganizer_Type_Decorator_RenameVariables( > new ScriptReorganizer_Type_Library ( new > ScriptReorganizer_Strategy_Empty ) > ); > > Here RenameVariables (or if you like: Obfuscate) is clearly an additional > and > optional functionality (decorator) one would like to add on top of the > _core_ > reorganization of the source. The possibilities of chaining are endless > ... OK, that's where I don't follow you... Why is RenameVariables a decorator rather than a strategy? Pack is also an additionnal functionnality (remove the unnecessary whitespaces), and it is optional (I can use quiet if I don't want to remove those whitespaces). I'm not sure what you mean about the "core reorganization of the source". I agree 100% that the decorator design allows that kind of thing, and that's why I proposed to use this design for strategies (or even to merge them since I'm still not sure about their differences). >> Or this could also be done by changing the way a >> strategy is applied to a code: >> >> $code->apply(new RenameVariables()); >> $code->apply(new Quiet()); > > Please be so kind to enlighten me regarding the following: at the stage of > instantiating a <Script> or <Library> object the _core_ <Strategy> to use > should already be known too, am I right? Right > So where is the need of deferring the "definiton" of the stratagy to > apply? Because it makes the syntax more simple and allows to use several strategies... It doesn't make sense to argue about that if I don't get what you call a strategy and what you call a decorator -- Vincent