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

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

A decorator lets you change the skin of an object; a strategy lets you change the guts.

Hum... RenameVariables seems to change as much the "guts" of the code than Pack...

No, because the "naming" does not imply the fact that it serves the main purpose of ScriptReorganizer to reduce the file size; see below.

The strategies Pack, Quiet and Route are just different variation of the same core responsibility - the mandatory behavior as I have defined it (reduction of the file's size).

As I see it, RenameVariable achieve the same goal by giving shorter names to the variables

Again, the name does not give a clue in this respect. As an "outsider", seeing only the name and not looking at the documentation, I can only figure out that variables will be renamed. Perhaps your class will expand variable names in the for-construct from $i to $index? If you would use a name like e.g. CompactVariableName or TruncateVariableName then I'm with you, for with your below stated suggestion of chaining strategies it makes sense.

The decorators AddHeader, AddFooter and Pharize are responsibilities that can be withdrawn without affecting the object (and its responsibility) in discussion.

The Pack strategy (remove the unnecessary whitespaces) could be seen as a decorator that can be withdrawn or not...

No, because the main responsibility of a Type object is to reduce the file size (I know that I'm repeating myself a lot now ...) and Pack is one varying implementation of the Strategy to use to achieve the goal.

ANN: That's the reason why I see RenameVariables as a decorator and not as a strategy. Depending on how it would be implemented as well as how the source to reorganize is structured, it could eventually even increase the files' size and thus not comply with the ScriptReorganizer's "contract".

I'm not sure we should define in a class is a subclass of another one by looking at it's implementation.

Sorry for any misunderstanding due to my lack in writing. I have not looked at the implementation of RenameVariable (I have not seen the source up to now ;-), but only at the name. ... see the discussion above in this respect.

Do you also mean that decorators *HAVE* to increase the size of the code? (Pharize may not respect this since the code may be compressed).

Vincent, Pharize will (most probably always) increase the file size even with compression in comparison to a Library, because PHP_Archive_Creator bundles PHP_Archive into the PHAR to create and AFAIK does not remove any code documentation etc.! The main idea with the decorator Pharize is to create a (possibly compressed) PHAR with <Pack>ed <Script>s. The combination of both techniques is the key to success. Thus Pharize "decorates" a <Type> object.

I still can't see why changing the indenting of the code and changing the variable names can't be seen as the same object... Rename variable seems to me a valid strategy to reduce the code size, and addHeader / addFooters seem to me valid strategies to "reorganize the script".

Reply to RenameVariable: see above. Regarding AddHeader and AddFooter: they only ADD something (which, generally speaking, is a reorganization too) and do NOT REDUCE the file size, therefore do not qualify as strategies. I'm trying very hard to keep these two concepts separated ... ;-)

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.