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

On Fri, 20 May 2005 02:27:33 +0200, Stefano F. Rausch <pear@sf.rausch-e.net> wrote:

On Thu, 19 May 2005 13:05:35 +0200, Vincent Lascaux <vincent.lascaux@centraliens.net> wrote:

It would even be really easy to write a addHeader decorator: class ScriptReorganizer_Strategy_AddHeader implements ScriptReorganizer_Strategy {

    var $inner;
    var $header;
    public __construct($header, ScriptReorganizer_Strategy $inner = null)
    {
        $this->header = $header;
        $this->inner = $inner;
    }
    public function reformat(& $content)
    {
        if ($inner != null) {
            $inner->reformat($content);
        }
        $content = $header . $content;
    }

} It looks easier to understand, quite similar to the code of other strategies... and more coherent to me.

Now it does ring a bell and I understand what you have thought of with saying "why not implement the stratagies as decorators?". That's definitively food for thought!!! Nice, ... chaining of several decorators as well as chaining of several strategies, didn't think of that. THX. I will explore this avenue.

Vincent, although the idea of chaining stratagies is very appealing, I had to drop this approach specifically for ScriptReorganizer (I'll keep it in mind for future projects to come though ;-) ). To make a long story short here's just one e x a m p l e, which should emphasize the problem connected to the approach suggested by you, espacially regarding this package proposal - I assume that the strategies have been decoupled (as asked for by Vincent in one of the previous discussions), so that in this specific case Route only removes multiple consecutives blank lines, Quiet only removes single/multiLineComments and Pack only removes all unneeded white spaces incl. end of lines and you will have to chain these strategies to achieve the combination of all three: What happens, if you want to chain the Route and the Pack strategy? Should both combination have the same output, i.e. P(R) === R(P)? How can you achieve this with keeping in mind that requirements will _always_ change and that new strategies will (eventually) come along to be considered too - if the chaining list to build gets longer? In this example the Route strategy can be left out, for Package is the dominant one and will always rule out Route. So here is no gain for this specific chain list. Furthermore, and even more important is the fact that, if you don't "quiet" the content to be reorganized (i.e. remove comments) before applying the "pack" algorithm, you just get a mess: you only need one singleLineComment in the top region of the script to process and the rest of the file will have "no meaning" any more ... this is because Pack, amongst others, removes all PHP_EOL to create a new file as compact as possible. This behaviour could be optional, but then the issue would not have been resolved ... So you see, the strategies Quiet and Pack have in-/direct dependencies, which are needed to work effectively. For this reason I will stick to the design proposed, which, after re-evaluating, still is a very good one for the goal to achieve: the optimization of source code size-wise. The strategies are and should be geared towards the only goal ScriptReorganizer was designed for. Still, the approach you are suggesting can be implemented by users feeling the need to. They just have to define a new strategy with the feature of accepting others for chaining - ScriptReorganizer doesn't mind. For the strategies I have implemented it does (unfortunately) not make sense. The decorators are only a "nice to have" additions for needs that I, for the time being, can not fully be aware of - I don't want to close this door. The Decorator Pattern ensures a plug-in functionality, which IMHO is good to have. This design (the combination of the Strategy Pattern and the Decorator Pattern) is flexible and extendable, leaving room for every user to craft further features as needed, without the need of changing the core package, by following the Open Closed Principle (OCP). Feel free, to come up with a better one, by all means! Again, thanks for all your input and thoughts regarding ScriptReorganizer. Your comments have been definitively food for thoughts. -- Stefano