RE: [digester] variable expansion

[ASHWIN Suresh <a....@sigmatel.net.ma>]

Sorry to jump in to this thread this way, and perhaps it is too late now.
But, have the people here considered using the term "resolve"
for this concept?

Perhaps the interface could be named Resolver, with the method resolve().

I can think of ${foo} > xyz as resolving the definition rather than simple
substitution,
thow at a lower level of abstraction, it is substitution.

If this has been considered and vetoed, please ignore my email.

One more point:

> The spelling "substituter" feels more natural to me than 
> "substitutor".
> 
> cf.:
> to write --> writer
> to drive --> driver
> to expand --> expander


For Latinate words, the pattern is usually -or.
Constructor, translator, delegator, etc.
Whenever, the agent form is formed out of removal of -ion, the preferred
suffix is -or.
Thus, the more appropriate form is substitutor.
Again, perhaps this was already discussed.

Ash





> -----Original Message-----
> From: Simon Kitching [mailto:s_kitching@paradise.net.nz]
> Sent: Thursday, December 04, 2003 09:18
> To: commons-dev@jakarta.apache.org
> Cc: simon@ecnetwork.co.nz
> Subject: [digester] variable expansion
> 
> 
> Hi Robert,
> 
> I think the code committed is just fine.
> 
> I like the versatile "Substitutor" interface; I can imagine 
> all sorts of
> uses for the ability to arbitrarily manipulate attribute 
> values and body
> text before rules see them other than just var expansion.
> 
> I also like the separation of this code out into a package, with only
> the Substitutor interface in the main code.
> 
> Some *very* minor comments: 
> 
> --
> 
> In VariableSubstitutor, you use lazy creation for variableAttributes.
> I'm not sure there is much point to that. Given that the user 
> has set up
> var expansion in the first place, the object will almost certainly be
> created sometime. However the existing code has to evaluate an
> if-statement on each call to determine if the object already exists. I
> think it also makes the code more complex than it needs to be. Why not
> create it in the constructor as soon as it is known if there is an
> attributeExpander or not?
> 
> --
> 
> I think a comment is needed in the Substitutor "interface" specifying
> that Digester guarantees never to hold the return value of the
> substitute(Attributes) method past the next call to the method. It is
> this behaviour that allows a single VariableAttributes object to be
> reused by the VariableSubstitutor. This behaviour was obvious before,
> when VariableAttributes was directly invoked from the Digester's
> startElement method, but probably needs to be explicitly 
> documented now.
> 
> --
> 
> You mention that you were considering whether it is necessary to have
> Remy's VarExpander implementation as well as the 
> MultiVariableExpander.
> While it would be a shame to discard Remy's work, I don't see much
> benefit from having an additional implementation.
> 
> The MultiVariableExpander does:
>         for(int i=0; i<nEntries; ++i) {
>             param = expand(
>                 param, 
>                 (String) markers.get(i), 
>                 (Map) sources.get(i));
>         }
>         return param;
> 
> The call to "expand" in the loop does exactly the same work as an
> implementation that supports only "${foo}" would do.
> 
> The overhead of looping once (ie nEntries=1) is trivial. The 
> overhead of
> fetching the marker and map from ArrayLists and casting them 
> is slightly
> higher, but still pretty small I think. That's the only performance
> difference I can see from an implementation customised for ant-like
> variables only. Oh - and avoiding one string concatenation in 
> the expand
> method ("$" + "{").
> 
> The API would be *very* slightly simpler: setSource(map) rather than
> addSource("$", map). I think this is more than offset by the 
> complexity
> of having multiple VarExpander implementations to choose from.
> 
> If the consensus is that the MultiVariableExpander is ok to 
> use for the
> simple case too, then it would probably make sense to rename it (eg
> BaseVariableExpander).
> 
> --
> 
> The spelling "substituter" feels more natural to me than 
> "substitutor".
> 
> cf.:
> to write --> writer
> to drive --> driver
> to expand --> expander
> 
> 
> Cheers,
> 
> Simon
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [digester] variable expansion

[robert burrell donkin <ro...@blueyonder.co.uk>]

hi ash
On 3 Dec 2003, at 09:59, ASHWIN Suresh wrote:

> Sorry to jump in to this thread this way, and perhaps it is too late 
> now.
> But, have the people here considered using the term "resolve"
> for this concept?
>
> Perhaps the interface could be named Resolver, with the method 
> resolve().
>
> I can think of ${foo} > xyz as resolving the definition rather than 
> simple
> substitution,
> thow at a lower level of abstraction, it is substitution.
>
> If this has been considered and vetoed, please ignore my email.

i'm usually pretty bad on naming at the best of times - and worse when 
i'm tied (too many lists, too little sleep 8-)

but i think that substitution is what the top level interface does 
(rather than resolution).

resolver is also an overused word in xml. we'd probably need to prefix 
it with an adjective -  VariableResolver, say. i think that 
VariableResolver is probably a slightly better name than 
VariableExpander for the interface decoupling the variable 
expansion/resolution implementation  but i think that simon's original 
name is very reasonable. i'd be happy to go with the consensus on this. 
comments anyone?

> One more point:
>
>> The spelling "substituter" feels more natural to me than
>> "substitutor".
>>
>> cf.:
>> to write --> writer
>> to drive --> driver
>> to expand --> expander
>
>
> For Latinate words, the pattern is usually -or.
> Constructor, translator, delegator, etc.
> Whenever, the agent form is formed out of removal of -ion, the 
> preferred
> suffix is -or.
> Thus, the more appropriate form is substitutor.
> Again, perhaps this was already discussed.

you seem to have put a lot more thought into it than i did :)

i intended it as a bit of a play on words - substitutor ~ terminator. 
digester has an 'e' but 'o' is probably better grammar. again, i be 
happy to bow to consensus. views anyone?

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: [digester] variable expansion

[Simon Kitching <si...@ecnetwork.co.nz>]

On Wed, 2003-12-03 at 22:59, ASHWIN Suresh wrote:
> Sorry to jump in to this thread this way, and perhaps it is too late now.
> But, have the people here considered using the term "resolve"
> for this concept?

I don't think it is too late for suggestions like this. Any time before
the release is not too late :-)

> Perhaps the interface could be named Resolver, with the method resolve().
> 
> I can think of ${foo} > xyz as resolving the definition rather than simple
> substitution,
> thow at a lower level of abstraction, it is substitution.

The concept of "substitution" is general; expanding/resolving variables
is just one application of the "substitution" feature. Possibly
"substitution" could be called "interception", "filtering",
"pre-processing", "manipulation". 

The "VarExpander" is implemented using the generic "substitution" mechanism.
I could go for "VarResolver" if other people like the term. The word "Resolver"
on its own, however, implies the SAX EntityResolver to me; at least that's what 
I would think of first..


Note that the string to which "var expansion" (in the current terminology) 
is being applied can have multiple variables mixed with literal data. 
For example:
  "this is a ${var} and so is ${this}"
Is the process of converting this string to its final form "resolving"?
I'm going to sit firmly on the fence on this one :-)

> 
> If this has been considered and vetoed, please ignore my email.

We haven't really talked about the terminology for this feature.
I think it is open for discussion. Good names help in so many ways.

> 
> One more point:
> 
> > The spelling "substituter" feels more natural to me than 
> > "substitutor".
> > 
> > cf.:
> > to write --> writer
> > to drive --> driver
> > to expand --> expander
> 
> 
> For Latinate words, the pattern is usually -or.
> Constructor, translator, delegator, etc.
> Whenever, the agent form is formed out of removal of -ion, the preferred
> suffix is -or.
> Thus, the more appropriate form is substitutor.
> Again, perhaps this was already discussed.

Yep, all your examples are right to have "-or".
And also function-->functor.

I'm convinced. Substitutor it is (unless the decision is made to rename
it completely :-)

English is strange, isn't it? Substitutor but Expander and Resolver.
How consistent (not)!




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org