[lang] text.Interpolation, on to 2.2

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
> -----Original Message-----
> From: Stephen Colebourne [mailto:[hidden email]]
> Sent: Wednesday, July 06, 2005 4:11 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text.Interpolation, on to 2.2
>
> Gary Gregory wrote:
> >>The source of values for the VariableFormat class is only allowed to
be
> >>a Map. I'm not sure if people will want other types of data sources.
> >
> >>Yes the resolveVariable method does allow customisation via
subclassing
>  >>but the fact that the "default" source is a map is very obviously
> exposed
> >>via the class API.
> >
> > Well, should we go back to the interface approach?
>
> The constrast is with the StrTokenizer class. That alread has an
> interface, and various implementations of the interface. Thus an
> interface for this class is not inapropriate.

I did like the interface approach, I'll take a look at putting it back
in to see how that feels.

>
> I was hoping that there might have been some way to take the
> StrTokenizer interface and make it top level and reuse it in all the
> classes in the text package. Perhaps for locating the delimiters in
> VariableFormatter. But I'm not sure that idea works.

I like the idea of eating our own dog food but I do not know how
practical or easy VariableFormatter can be made to reuses a
StrTokenizer. Perhaps Oliver can opine on this.

> Considering the current VariableFormatter class:
>
> a) we don't have the ability to call it directly from StrBuilder
without
> copying the char array to a String. (VariableFormatter needs rewriting
> to operate on a char[])
>
> b) we have lost the ability to have multiple substitutions

What do you mean here?

Gary



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Oliver Heger-2
In reply to this post by Stephen Colebourne
Some comments inline...

Stephen Colebourne wrote:

> Gary Gregory wrote:
>
>>> The source of values for the VariableFormat class is only allowed to be
>>> a Map. I'm not sure if people will want other types of data sources.
>>
>>
>>> Yes the resolveVariable method does allow customisation via subclassing
>>
> >>but the fact that the "default" source is a map is very obviously
> exposed
>
>>> via the class API.
>>
>>
>> Well, should we go back to the interface approach?
>
>
> The constrast is with the StrTokenizer class. That alread has an
> interface, and various implementations of the interface. Thus an
> interface for this class is not inapropriate.
>
> I was hoping that there might have been some way to take the
> StrTokenizer interface and make it top level and reuse it in all the
> classes in the text package. Perhaps for locating the delimiters in
> VariableFormatter. But I'm not sure that idea works.
>
>
> Considering the current VariableFormatter class:
>
> a) we don't have the ability to call it directly from StrBuilder
> without copying the char array to a String. (VariableFormatter needs
> rewriting to operate on a char[])

Okay, to remain consistency this point sounds reasonable. If
VariableFormatter is reworked to operate on a char[], StrTokenizer will
certainly be useful. I think, it shouldn't be a problem to implement the
Matcher interface to locate variables in the source string. But I will
have to study the StrTokenizer class whether it is possible to extract
the variables' names once they have been detected.

>
> b) we have lost the ability to have multiple substitutions

I don't understand what you mean with this point.

>
> c) we have added a complex escaping mechanism

That's true, escaping increases complexity. I think we will have to find
a consense how far we want to go in this area. If you are in control
over the input for VariableFormatter, escaping might not be an issue
because you can choose variable delimiters that do not conflict with the
output you want to generate. But if this is not the case, the use case
of escaping variables will sooner or later come in naturally.

>
> d) we don't have a replaceOnce() method

This could be realized by passing a noRecursive flag to the main
substitution method; if this flag is set, no recursive calls will be made.

>
> I would hope that we could have a static method, that is passed all
> the state, and performs all the work. That way it can be called from
> StrBuilder in the most efficient way. And StrTokenizer should be
> rewritten like this too.

This is a good point. The main replace method could be implemented as a
static method, but we would then lose the possibility of overloading the
resolveVariable() method to extend the provided functionality. So in
this case I would prefer to have a VariableResolver interface (instead
of a plain map), which will support customization more easily.

>
> Stephen
>
Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Stephen Colebourne
>> a) we don't have the ability to call it directly from StrBuilder
>> without copying the char array to a String. (VariableFormatter needs
>> rewriting to operate on a char[])

Hmmm. I've just realised that this won't work. VariableFormatter may
need to lengthen the array, and that isn't possible outside the
StrBuilder class (without horrible hacks).

So, IMHO, we need to focus on StrBuilder again. StrBuilder is intended
as our mutable string. VariableFormatter can use a StrBuilder intenally.

StrTokenizer doen't need to use StrBuilder as it doesn't change the
string. VariableFormatter does change the string, so should be built on
StrBuilder.


Oliver Heger wrote:
> I think, it shouldn't be a problem to implement the
> Matcher interface to locate variables in the source string. But I will
> have to study the StrTokenizer class whether it is possible to extract
> the variables' names once they have been detected.

My point wrt StrTokenizer was that the Matcher interface *might* be
useful. However, on further reflection, I think it is best to keep the
two classes a bit more separate. We shouldn't force re-use.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
In reply to this post by Gary Gregory
In-lined at the end ... G

> From: Stephen Colebourne [mailto:[hidden email]]
> Sent: Saturday, July 09, 2005 6:32 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text.Interpolation, on to 2.2
>
> >> a) we don't have the ability to call it directly from StrBuilder
> >> without copying the char array to a String. (VariableFormatter
needs
> >> rewriting to operate on a char[])
>
> Hmmm. I've just realised that this won't work. VariableFormatter may
> need to lengthen the array, and that isn't possible outside the
> StrBuilder class (without horrible hacks).
>
> So, IMHO, we need to focus on StrBuilder again. StrBuilder is intended
> as our mutable string. VariableFormatter can use a StrBuilder
intenally.
>
> StrTokenizer doen't need to use StrBuilder as it doesn't change the
> string. VariableFormatter does change the string, so should be built
on
> StrBuilder.
>
>
> Oliver Heger wrote:
> > I think, it shouldn't be a problem to implement the
> > Matcher interface to locate variables in the source string. But I
will
> > have to study the StrTokenizer class whether it is possible to
extract
> > the variables' names once they have been detected.
>
> My point wrt StrTokenizer was that the Matcher interface *might* be
> useful. However, on further reflection, I think it is best to keep the
> two classes a bit more separate. We shouldn't force re-use.

I agree, and in this spirit I would want VariableFormatter to only use
StrBuilder because it needs to, not because it is just there.

Gary

> Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
In reply to this post by Gary Gregory
I would like us to reconsider the use of the VariableResolver interface
for VariableFormatter.

It seems that this is a cleaner design that does not force subclassing
or composition as the sole mean of feature extension.

Considering the complexity of the StrTokenizer class, I do not think
that the earlier concern that VariableFormatter+VariableResolver as too
framework-like is really valid.

The interface VariableResolver could be made to live in the
VariableFormatter class we *really* think we need to "hide" this
feature.

If Oliver is up for it and the list does not say "no, no, because...",
I'd like to see a patch to the CVS code that makes VariableFormatter use
a VariableResolver with an canned implementation for Maps.

Gary

> -----Original Message-----
> From: Oliver Heger [mailto:[hidden email]]
> Sent: Saturday, July 09, 2005 2:38 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text.Interpolation, on to 2.2
>
> Some comments inline...
>
> Stephen Colebourne wrote:
>
> > Gary Gregory wrote:
> >
> >>> The source of values for the VariableFormat class is only allowed
to
> be
> >>> a Map. I'm not sure if people will want other types of data
sources.

> >>
> >>
> >>> Yes the resolveVariable method does allow customisation via
> subclassing
> >>
> > >>but the fact that the "default" source is a map is very obviously
> > exposed
> >
> >>> via the class API.
> >>
> >>
> >> Well, should we go back to the interface approach?
> >
> >
> > The constrast is with the StrTokenizer class. That alread has an
> > interface, and various implementations of the interface. Thus an
> > interface for this class is not inapropriate.
> >
> > I was hoping that there might have been some way to take the
> > StrTokenizer interface and make it top level and reuse it in all the
> > classes in the text package. Perhaps for locating the delimiters in
> > VariableFormatter. But I'm not sure that idea works.
> >
> >
> > Considering the current VariableFormatter class:
> >
> > a) we don't have the ability to call it directly from StrBuilder
> > without copying the char array to a String. (VariableFormatter needs
> > rewriting to operate on a char[])
>
> Okay, to remain consistency this point sounds reasonable. If
> VariableFormatter is reworked to operate on a char[], StrTokenizer
will
> certainly be useful. I think, it shouldn't be a problem to implement
the

> Matcher interface to locate variables in the source string. But I will
> have to study the StrTokenizer class whether it is possible to extract
> the variables' names once they have been detected.
>
> >
> > b) we have lost the ability to have multiple substitutions
>
> I don't understand what you mean with this point.
>
> >
> > c) we have added a complex escaping mechanism
>
> That's true, escaping increases complexity. I think we will have to
find
> a consense how far we want to go in this area. If you are in control
> over the input for VariableFormatter, escaping might not be an issue
> because you can choose variable delimiters that do not conflict with
the
> output you want to generate. But if this is not the case, the use case
> of escaping variables will sooner or later come in naturally.
>
> >
> > d) we don't have a replaceOnce() method
>
> This could be realized by passing a noRecursive flag to the main
> substitution method; if this flag is set, no recursive calls will be
made.
>
> >
> > I would hope that we could have a static method, that is passed all
> > the state, and performs all the work. That way it can be called from
> > StrBuilder in the most efficient way. And StrTokenizer should be
> > rewritten like this too.
>
> This is a good point. The main replace method could be implemented as
a
> static method, but we would then lose the possibility of overloading
the

> resolveVariable() method to extend the provided functionality. So in
> this case I would prefer to have a VariableResolver interface (instead
> of a plain map), which will support customization more easily.
>
> >
> > Stephen
> >
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Oliver Heger-2
Gary Gregory wrote:

>I would like us to reconsider the use of the VariableResolver interface
>for VariableFormatter.
>
>It seems that this is a cleaner design that does not force subclassing
>or composition as the sole mean of feature extension.
>
>Considering the complexity of the StrTokenizer class, I do not think
>that the earlier concern that VariableFormatter+VariableResolver as too
>framework-like is really valid.
>
>The interface VariableResolver could be made to live in the
>VariableFormatter class we *really* think we need to "hide" this
>feature.
>
>If Oliver is up for it and the list does not say "no, no, because...",
>I'd like to see a patch to the CVS code that makes VariableFormatter use
>a VariableResolver with an canned implementation for Maps.
>
>Gary
>  
>
I prefer the VariableResolver approach, too. So if nobody objects, I
will create a patch, which re-introduces this interface (as an inner
class) and makes all methods static. (With this approach there is no
need for creating instances of VariableFormatter, right?)

Don't know how much time I have in the next days, so this might take
some days.

Oliver

<snip/>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
In reply to this post by Gary Gregory
Hello VariableFormatters:

I've retro-fitted the VariableResolver interface into the
VariableFormatter class and provided a Map-backed VariableResolver
implementation. I did not change everything to statics.

I think (and hope) this approach provides an API to address the most
common cases (Map) with the ability to extend functionality by
implementing your own VariableResolver and possibly subclassing.

If Oliver and others could see how this looks and feels to them I would
appreciate any and all comments; in particular as to the use for
[configuration].

Thanks,
Gary

> -----Original Message-----
> From: Oliver Heger [mailto:[hidden email]]
> Sent: Sunday, July 10, 2005 11:45 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text.Interpolation, on to 2.2
>
> Gary Gregory wrote:
>
> >I would like us to reconsider the use of the VariableResolver
interface
> >for VariableFormatter.
> >
> >It seems that this is a cleaner design that does not force
subclassing
> >or composition as the sole mean of feature extension.
> >
> >Considering the complexity of the StrTokenizer class, I do not think
> >that the earlier concern that VariableFormatter+VariableResolver as
too
> >framework-like is really valid.
> >
> >The interface VariableResolver could be made to live in the
> >VariableFormatter class we *really* think we need to "hide" this
> >feature.
> >
> >If Oliver is up for it and the list does not say "no, no,
because...",
> >I'd like to see a patch to the CVS code that makes VariableFormatter
use

> >a VariableResolver with an canned implementation for Maps.
> >
> >Gary
> >
> >
> I prefer the VariableResolver approach, too. So if nobody objects, I
> will create a patch, which re-introduces this interface (as an inner
> class) and makes all methods static. (With this approach there is no
> need for creating instances of VariableFormatter, right?)
>
> Don't know how much time I have in the next days, so this might take
> some days.
>
> Oliver
>
> <snip/>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Oliver Heger-2
Hello Gary,

the current state of VariableFormatter is fine with me, it allows me
everything to do I need for [configuration].

I think the problem will be to satisfy other needs mentioned by others
in this thread (e.g. operating on a char[], a static interpolation
method that works without creating an instance). But these points are
less important for me.

Oliver

Gary Gregory wrote:

>Hello VariableFormatters:
>
>I've retro-fitted the VariableResolver interface into the
>VariableFormatter class and provided a Map-backed VariableResolver
>implementation. I did not change everything to statics.
>
>I think (and hope) this approach provides an API to address the most
>common cases (Map) with the ability to extend functionality by
>implementing your own VariableResolver and possibly subclassing.
>
>If Oliver and others could see how this looks and feels to them I would
>appreciate any and all comments; in particular as to the use for
>[configuration].
>
>Thanks,
>Gary
>
>  
>
>>-----Original Message-----
>>From: Oliver Heger [mailto:[hidden email]]
>>Sent: Sunday, July 10, 2005 11:45 AM
>>To: Jakarta Commons Developers List
>>Subject: Re: [lang] text.Interpolation, on to 2.2
>>
>>Gary Gregory wrote:
>>
>>    
>>
>>>I would like us to reconsider the use of the VariableResolver
>>>      
>>>
>interface
>  
>
>>>for VariableFormatter.
>>>
>>>It seems that this is a cleaner design that does not force
>>>      
>>>
>subclassing
>  
>
>>>or composition as the sole mean of feature extension.
>>>
>>>Considering the complexity of the StrTokenizer class, I do not think
>>>that the earlier concern that VariableFormatter+VariableResolver as
>>>      
>>>
>too
>  
>
>>>framework-like is really valid.
>>>
>>>The interface VariableResolver could be made to live in the
>>>VariableFormatter class we *really* think we need to "hide" this
>>>feature.
>>>
>>>If Oliver is up for it and the list does not say "no, no,
>>>      
>>>
>because...",
>  
>
>>>I'd like to see a patch to the CVS code that makes VariableFormatter
>>>      
>>>
>use
>  
>
>>>a VariableResolver with an canned implementation for Maps.
>>>
>>>Gary
>>>
>>>
>>>      
>>>
>>I prefer the VariableResolver approach, too. So if nobody objects, I
>>will create a patch, which re-introduces this interface (as an inner
>>class) and makes all methods static. (With this approach there is no
>>need for creating instances of VariableFormatter, right?)
>>
>>Don't know how much time I have in the next days, so this might take
>>some days.
>>
>>Oliver
>>
>><snip/>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] text.Interpolation, on to 2.2

Gary Gregory
In reply to this post by Gary Gregory
> From: Oliver Heger [mailto:[hidden email]]
> Sent: Sunday, July 17, 2005 12:11 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text.Interpolation, on to 2.2
>
> Hello Gary,
>
> the current state of VariableFormatter is fine with me, it allows me
> everything to do I need for [configuration].
>
> I think the problem will be to satisfy other needs mentioned by others
> in this thread (e.g. operating on a char[], a static interpolation
> method that works without creating an instance). But these points are
> less important for me.
>
> Oliver


Oliver: Ok, good new.

All:

(1) operating on a char[]

I recall seeing a mention of this earlier but I cannot recall the
driving force for it. Could it be done in a subsequent release or at
least once we are all happy with the String version? We could the double
up with char[] version of the String APIs. Not my favorite but if it
really needed, it is.

(2) static interpolation method that works without creating an instance.

This is also not important to me but I am open to chatting about it.

(3) I would like to remove the two other classes. I'll propose that in
another message to make it more visible when we are more settled with
VariableFormatter WRT 1 and 2 above.

Thanks,
Gary

>
> Gary Gregory wrote:
>
> >Hello VariableFormatters:
> >
> >I've retro-fitted the VariableResolver interface into the
> >VariableFormatter class and provided a Map-backed VariableResolver
> >implementation. I did not change everything to statics.
> >
> >I think (and hope) this approach provides an API to address the most
> >common cases (Map) with the ability to extend functionality by
> >implementing your own VariableResolver and possibly subclassing.
> >
> >If Oliver and others could see how this looks and feels to them I
would

> >appreciate any and all comments; in particular as to the use for
> >[configuration].
> >
> >Thanks,
> >Gary
> >
> >
> >
> >>-----Original Message-----
> >>From: Oliver Heger [mailto:[hidden email]]
> >>Sent: Sunday, July 10, 2005 11:45 AM
> >>To: Jakarta Commons Developers List
> >>Subject: Re: [lang] text.Interpolation, on to 2.2
> >>
> >>Gary Gregory wrote:
> >>
> >>
> >>
> >>>I would like us to reconsider the use of the VariableResolver
> >>>
> >>>
> >interface
> >
> >
> >>>for VariableFormatter.
> >>>
> >>>It seems that this is a cleaner design that does not force
> >>>
> >>>
> >subclassing
> >
> >
> >>>or composition as the sole mean of feature extension.
> >>>
> >>>Considering the complexity of the StrTokenizer class, I do not
think

> >>>that the earlier concern that VariableFormatter+VariableResolver as
> >>>
> >>>
> >too
> >
> >
> >>>framework-like is really valid.
> >>>
> >>>The interface VariableResolver could be made to live in the
> >>>VariableFormatter class we *really* think we need to "hide" this
> >>>feature.
> >>>
> >>>If Oliver is up for it and the list does not say "no, no,
> >>>
> >>>
> >because...",
> >
> >
> >>>I'd like to see a patch to the CVS code that makes
VariableFormatter

> >>>
> >>>
> >use
> >
> >
> >>>a VariableResolver with an canned implementation for Maps.
> >>>
> >>>Gary
> >>>
> >>>
> >>>
> >>>
> >>I prefer the VariableResolver approach, too. So if nobody objects, I
> >>will create a patch, which re-introduces this interface (as an inner
> >>class) and makes all methods static. (With this approach there is no
> >>need for creating instances of VariableFormatter, right?)
> >>
> >>Don't know how much time I have in the next days, so this might take
> >>some days.
> >>
> >>Oliver
> >>
> >><snip/>
> >>
> >>
>
>>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [hidden email]
> >For additional commands, e-mail: [hidden email]
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] text.Interpolation, on to 2.2

Oliver Heger-2
Gary Gregory wrote:

>>From: Oliver Heger [mailto:[hidden email]]
>>Sent: Sunday, July 17, 2005 12:11 PM
>>To: Jakarta Commons Developers List
>>Subject: Re: [lang] text.Interpolation, on to 2.2
>>
>>Hello Gary,
>>
>>the current state of VariableFormatter is fine with me, it allows me
>>everything to do I need for [configuration].
>>
>>I think the problem will be to satisfy other needs mentioned by others
>>in this thread (e.g. operating on a char[], a static interpolation
>>method that works without creating an instance). But these points are
>>less important for me.
>>
>>Oliver
>>    
>>
>
>
>Oliver: Ok, good new.
>
>All:
>
>(1) operating on a char[]
>
>I recall seeing a mention of this earlier but I cannot recall the
>driving force for it. Could it be done in a subsequent release or at
>least once we are all happy with the String version? We could the double
>up with char[] version of the String APIs. Not my favorite but if it
>really needed, it is.
>
>(2) static interpolation method that works without creating an instance.
>
>This is also not important to me but I am open to chatting about it.
>
>(3) I would like to remove the two other classes. I'll propose that in
>another message to make it more visible when we are more settled with
>VariableFormatter WRT 1 and 2 above.
>
>Thanks,
>Gary
>
>  
>
I see there was not much feedback for (1) and (2).

While being content with the functionality provided by
VariableFormatter, I have got the feeling that the implementation could
be improved. For instance the escaping mechanism is really complex ATM
and could surely be simplified.

I have some ideas how to do this and how this can be achieved by
directly operating on a char[]. I would like to play a bit around with
these topics with the aim to make the code easier to understand and more
integrated with the other [lang] classes (especially in the text
package). Next week I will be traveling, but hopefully find some time to
deal with these issues.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123