Re: [digester] variable expansion
On 3 Dec 2003, at 22:46, Simon Kitching wrote: On Fri, 2003-12-05 at 11:17, Simon Kitching wrote: Hi Robert, I think the code committed is just fine. On further thought, I have a more significant change to suggest. I think the VariableSubstitutor and MultiVariableExpander classes should be merged. VariableSubstitutor really is a nothing class, just delegating all its work to other classes. but that's the beauty of that class :) (i'll expand later.) PRO: * one less class in the digester code base * one less class for the user to deal with. they just instantiate a BaseVariableSubstitutor (or whatever) rather than both a VariableSubstitutor and a MultiVariableExpander. CON: A user can't just write a new VariableExpander implementation; they need to write a new Substitutor implementation instead. However as noted above, the code currently in VariableSubstitutor is pretty trivial; I can't see that being an issue in practice. it may be trivial but i have a strongly feeling that variation in this area will be required for many common use cases. for example, to substitute just attributes or to use a different system of variable encoding. by providing this trivial hook, the user only has to write the smallest possible amount of code (and they are required to learn only a small part of the design) in order to solve these common cases. i've found that it's often better to best to provide both the right general solution and an easy way to solve the most common customization use cases. often, this may lead to duplicate hook points (in this case, Substitution and VariableExpander) but it makes things easy for users (and for those who explain to users how do use libraries ;) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] variable expansion
hi simon On 4 Dec 2003, at 09:17, Simon Kitching wrote: 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? you're probably right. they'd be a small saving if a null expander was passed in but we're probably better trading that for code clarity. 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. yep. it's standard SAX behaviour but you're right about adding some javadocs for this. i should probably go through and add some extra javadocs explanations to the Rule methods saying that the Attributes may be recycled and should not be changed (but that'll have to wait till tomorrow). 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. 'm going to look into this. tomcat's an important user for digester and even if the differences are very minor (or of arguable value), i'd probably be inclined to include both. i do think that probably your implementation provides everything that remy's does but i want to take some time to analyze it properly. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] variable expansion
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] variable expansion
-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
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 :-)
Glad abt that!
> 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".
I would go with you. Substitution is more generic, while resolving and
expanding are more specific activities. Then can it be said that the package
ought to be substitution, which contains classes (or perhaps methods within
a class) that do more specific things like resolving and expanding??
Trying to make things more concrete:
Substitution: f(x) > y
Resolution: f(x) > y where,
x is explicitly a resolvabe, indicated by special symbols (escapes): such as
${} and &;.
Expansion: f(x) > y where,
y is "longer" than x, conversely, x can be viewed as a
shorter/contracted/abreviated form of y.
Replacement: f(x) > y
A simple replacement of x by y. (Thow the term substitution itself can carry
this meaning, we "decide" to use that one with a higher/more generic value.)
Pre-processing:
When any kind of manipulation takes place BEFORE any kind of processing!
Sounds simple eh.
Filtering: f(x) > y
Where sometimes x = y, and at other times, x gives a y that is distinct.
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..
There you are. Entities are another set of "resolvables", that get
resolved. So, let's say, we are on track, but here, we are doing variable
resolving.
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 :-)
Just getting the equivalent of ${var} is variable resolving. Do you propose
another term for the whole process?
> > 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.
Name game, am game!
Besides, what did draw my attention too was that I had only recently
implemented some code to "resolve" an ant-like variable to its final value.
> > 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 :-)
Funnily, digester then must be renamed to digestor!
("Now, who's that feisty suggestor?", would you say? ;-))
English is strange, isn't it? Substitutor but Expander and Resolver.
How consistent (not)!
Strange it is. But there are reasons underlying it. Etymology being one of
my passions, I have unearthed some of the reasons, but more on that, another
day, and perhaps on another list.
Ash
_
Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] variable expansion
On Fri, 2003-12-05 at 11:17, Simon Kitching wrote: > Hi Robert, > > I think the code committed is just fine. On further thought, I have a more significant change to suggest. I think the VariableSubstitutor and MultiVariableExpander classes should be merged. VariableSubstitutor really is a nothing class, just delegating all its work to other classes. If it is decided to have just one implementation that handles both the simple ant-like case, and the more complex implementation currently in MultiVariableExpander, then the resulting class name could be "BaseVariableSubstitutor", otherwise it could be called MultiVariableSubstitutor. I suggest that the (new) BaseVariableSubstitutor should implement both Substitutor and VariableExpander, and pass itself to the VariableAttributes class as the expander to use. This does mean that the constructor would need to change: public BaseVariableSubstitutor(boolean doAttributes, boolean doBody) PRO: * one less class in the digester code base * one less class for the user to deal with. they just instantiate a BaseVariableSubstitutor (or whatever) rather than both a VariableSubstitutor and a MultiVariableExpander. CON: A user can't just write a new VariableExpander implementation; they need to write a new Substitutor implementation instead. However as noted above, the code currently in VariableSubstitutor is pretty trivial; I can't see that being an issue in practice. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] variable expansion
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [digester] variable expansion
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:[EMAIL PROTECTED]
> Sent: Thursday, December 04, 2003 09:18
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> 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 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
