Re: [PEPr] Comment on Tools and Utilities::ScriptReorganizer
| From: | Vincent Lascaux | Date: | Mon, 16 May 2005 20:30:54 +0000 |
| Subject: | Re: [PEPr] Comment on Tools and Utilities::ScriptReorganizer | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-37687@lists.php.net to get a copy of this message | ||
>> I don't think Type is a good name, Document would probably be better (if
>> I
>> understand what it does right: storing the document (script or library)
>> that will be transformed by a strategy).
>
> <Type>, as, without any doubts, you will have seen in the source, is the
> "abstract
> concept" of what _has_to_be_created_ and only by chance holds the
> "original
> document" to be processed. It's more the notion of what the output will
> be:
> "document" of <Type> script or of <Type> library, two different
> implementations
> of said concept.
OK... Looking at the code, it looks like Type is more like an abstract
concept of a job: its role is not only to represent some code, but also the
way it will be transformed (since it also stores the strategy and
(eventually) the decorator). I still think that this class should not hold
the strategies (or the decorators).
> What about the name <Code>, which, IMHO, does reflect even better what is
> being looked at - with "Document" I do associate more something to deal
> with a
> word processor, a grafical tool etc. Just a thought.
I also prefer Code: it's a more specific (and thus better) name than
Document. But a Code should not hold a decorator or a strategy, should it?
> I do follow you on this, but the reasoning behind the separation of
> stratagies and
> decorators is very simple:
>
> - Strategies are _mandatory_, i.e. it does not make sense to create a
> "Document"
> object without knowing in advance, which <Strategy> to apply (remember,
> that
> the context of ScriptReorganizer is the deployment of code and not a
> dynamic web
> application - it's just a work horse package) ... it simply can't be
> missed by chance
> and it's anchored with the instantiation of the "Document".
Actually, I find you library class (that implements Type) usefull, even
without applying any strategy. Strategies should not be mandatory, and it
would be nice if several strategies could be applied (like 1-remove
comments, 2-remove unusefull whitespaces, 3-add header).
Unrelated: I had a look to you library type, wouldn't you have a problem
with cyclic imports (like A.php contains require_once 'B.php'; and B.php
contains require_once 'A.php';)?
--
Vincent