[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

Simon Kitching
On Wed, 2005-06-29 at 01:38 +0200, Emmanuel Bourg wrote:
> Dumb question, why do we even need a VariableResolver interface ? A
> String->Object association is a common job for a Map after all. We
> should be able to build a sophisticated resolver system in
> [configuration] with a simple resolve(String, Map) method in [lang].

You mean that someone with special resolving requirements should provide
a custom class that implements Map?

That's doable I guess, and it does provide a unified API that is nice
for those cases where the source data really is in a standard Map object
(which will probably be the case 95% of the time).

However for the other cases the user has to implement the Map interface
which it's quite a lot of work. As the resolve method actually uses only
the "get" method on the map it seems a shame to require the user to
implement the full Map interface.

And the get method takes an Object key and returns an Object result,
whereas resolve always provides a String key and returns a String
result. So using a map means using types far more generic than
necessary; not fatal but not elegant.

Regards,

Simon


---------------------------------------------------------------------
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

Emmanuel Bourg-3
Simon Kitching wrote:

> You mean that someone with special resolving requirements should provide
> a custom class that implements Map?

Yes that's what I mean.


> However for the other cases the user has to implement the Map interface
> which it's quite a lot of work. As the resolve method actually uses only
> the "get" method on the map it seems a shame to require the user to
> implement the full Map interface.

On the other hand, if the resolve method guarantees that it will only
use the get() method from the Map interface, the user is free to let the
other methods unimplemented. The hint could be included in the javadoc,
this should be enough for the minority of users interested in
implementing a custom variable resolution.

Emmanuel Bourg


---------------------------------------------------------------------
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
Emmanuel Bourg wrote:

> Simon Kitching wrote:
>
>> You mean that someone with special resolving requirements should provide
>> a custom class that implements Map?
>
>
> Yes that's what I mean.
>
>
>> However for the other cases the user has to implement the Map interface
>> which it's quite a lot of work. As the resolve method actually uses only
>> the "get" method on the map it seems a shame to require the user to
>> implement the full Map interface.
>
>
> On the other hand, if the resolve method guarantees that it will only
> use the get() method from the Map interface, the user is free to let the
> other methods unimplemented. The hint could be included in the javadoc,
> this should be enough for the minority of users interested in
> implementing a custom variable resolution.
>
> Emmanuel Bourg
>
>

Okay, a map would be enough, but this would be a very minimalistic
solution. So if nobody of the [lang] committers had strong feelings
against such a simple VariableResolver interface (and a map-based
default implementation), I would prefer this approach.

One benefit is that an interface is always a hint for a developer that
it is possible to provide a different implementation. With an
interpolation method that only takes a map it is probably not as obvious
   that a specific map can be written to extend the existing functionality.

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

Gary Gregory
In reply to this post by Gary Gregory
Hi & wait a sec, you cannot just "let the other methods unimplemented",
the code will not compile. All interface methods must be implemented,
the bodies of void methods can be empty, others and can return nulls and
0's or throw exceptions, sure, but that seems confusing.

It seems simpler to have an interface with one method than to explain
that the resolver is a Map, but not really, and that, today, only this
here methods needs to be implemented. Or am I missing something?

Gary
-----Original Message-----
From: Emmanuel Bourg [mailto:[hidden email]]
Sent: Tuesday, June 28, 2005 6:26 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] text.Interpolation, on to 2.2

Simon Kitching wrote:

> You mean that someone with special resolving requirements should
provide
> a custom class that implements Map?

Yes that's what I mean.


> However for the other cases the user has to implement the Map
interface
> which it's quite a lot of work. As the resolve method actually uses
only
> the "get" method on the map it seems a shame to require the user to
> implement the full Map interface.

On the other hand, if the resolve method guarantees that it will only
use the get() method from the Map interface, the user is free to let the

other methods unimplemented. The hint could be included in the javadoc,
this should be enough for the minority of users interested in
implementing a custom variable resolution.

Emmanuel Bourg


---------------------------------------------------------------------
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
FWIW, I am a committer and I would prefer to see Oliver's approach. I am
open to discuss alternatives too of course.

(I read the message about Velocity but I'm not sure if I want to carry
the whole Velocity engine):

Here is my wishful thinking for this feature:

- Oliver's VariableResolver interface and what I'd like to call a
VariableFormat class (which was called Interpolation/Interpolator, names
I am not fond of).
- Extensible by [configuration]: The VariableResolver allows for
extension by [configuration].
- Easy to use with a Map (from System.getProperties()), which means that
a VariableMapResolver should to be provided I think. I would still like
to see an API that takes a Map (and uses the VariableMapResolver
internally) for simple looking call sites.

Gary

-----Original Message-----
From: Oliver Heger [mailto:[hidden email]]
Sent: Tuesday, June 28, 2005 11:53 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] text.Interpolation, on to 2.2

Emmanuel Bourg wrote:
> Simon Kitching wrote:
>
>> You mean that someone with special resolving requirements should
provide
>> a custom class that implements Map?
>
>
> Yes that's what I mean.
>
>
>> However for the other cases the user has to implement the Map
interface
>> which it's quite a lot of work. As the resolve method actually uses
only
>> the "get" method on the map it seems a shame to require the user to
>> implement the full Map interface.
>
>
> On the other hand, if the resolve method guarantees that it will only
> use the get() method from the Map interface, the user is free to let
the
> other methods unimplemented. The hint could be included in the
javadoc,
> this should be enough for the minority of users interested in
> implementing a custom variable resolution.
>
> Emmanuel Bourg
>
>

Okay, a map would be enough, but this would be a very minimalistic
solution. So if nobody of the [lang] committers had strong feelings
against such a simple VariableResolver interface (and a map-based
default implementation), I would prefer this approach.

One benefit is that an interface is always a hint for a developer that
it is possible to provide a different implementation. With an
interpolation method that only takes a map it is probably not as obvious

   that a specific map can be written to extend the existing
functionality.

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

Emmanuel Bourg-3
In reply to this post by Gary Gregory
Gary Gregory wrote:
> Hi & wait a sec, you cannot just "let the other methods unimplemented",
> the code will not compile. All interface methods must be implemented,
> the bodies of void methods can be empty, others and can return nulls and
> 0's or throw exceptions, sure, but that seems confusing.

By unimplemented I meant throwing an UnsupportedOperationException or
NotImplementedException for example, or returning a null value as you
suggested.

> It seems simpler to have an interface with one method than to explain
> that the resolver is a Map, but not really, and that, today, only this
> here methods needs to be implemented. Or am I missing something?

I think it would be simpler to use a standard interface rather than
introducing a new one that very few people will use. It looks to me like
a good compromise between simplicity and an approach that may look a bit
too "framework-ish" that Simon was concerned about.

Emmanuel Bourg

---------------------------------------------------------------------
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
Hm, I did not realize that being to f/w-ish was an issue, which is fine
and seems clear now.

How about this as a compromise (thinking aloud):

The (currently imaginary) class VariableFormat holds a Map and defines a
method VariableFormat#resolve(String name).

[configuration] can subclass the class and override the
VariableFormat#resolve(String name) to provide its own logic. This would
allow for the resolve by delegation scenario.

You would "normally" front-load a VariableFormat with a Map.

Oliver, would you consider this workable for [configuration]?

Gary

-----Original Message-----
From: Emmanuel Bourg [mailto:[hidden email]]
Sent: Wednesday, June 29, 2005 8:47 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] text.Interpolation, on to 2.2

Gary Gregory wrote:
> Hi & wait a sec, you cannot just "let the other methods
unimplemented",
> the code will not compile. All interface methods must be implemented,
> the bodies of void methods can be empty, others and can return nulls
and
> 0's or throw exceptions, sure, but that seems confusing.

By unimplemented I meant throwing an UnsupportedOperationException or
NotImplementedException for example, or returning a null value as you
suggested.

> It seems simpler to have an interface with one method than to explain
> that the resolver is a Map, but not really, and that, today, only this
> here methods needs to be implemented. Or am I missing something?

I think it would be simpler to use a standard interface rather than
introducing a new one that very few people will use. It looks to me like

a good compromise between simplicity and an approach that may look a bit

too "framework-ish" that Simon was concerned about.

Emmanuel Bourg

---------------------------------------------------------------------
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:

>Hm, I did not realize that being to f/w-ish was an issue, which is fine
>and seems clear now.
>
>How about this as a compromise (thinking aloud):
>
>The (currently imaginary) class VariableFormat holds a Map and defines a
>method VariableFormat#resolve(String name).
>
>[configuration] can subclass the class and override the
>VariableFormat#resolve(String name) to provide its own logic. This would
>allow for the resolve by delegation scenario.
>
>You would "normally" front-load a VariableFormat with a Map.
>
>Oliver, would you consider this workable for [configuration]?
>
>Gary
>
>  
>
Yes, this would perfectly work for [configuration].

And to gain more convenience when directly called the VariableFormat
class could still define a static method
String replace(String source, Map map), which would internally create an
instance, feed it with the passed in map and call the interpolation
method on this instance.

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

Gary Gregory
In reply to this post by Gary Gregory
Oliver wrote: " And to gain more convenience when directly called the
VariableFormat class could still define a static method String
replace(String source, Map map), which would internally create an
instance, feed it with the passed in map and call the interpolation
method on this instance."

Seems like a fine idea.

Oliver (or anyone else), would you be willing to take a first cut at
porting your patch in the Bugzilla ticket referred to earlier to this
current scheme?

We could then put it in CVS with unit tests and see how it feels to all
of us once in code form.

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

Stephen Colebourne
In reply to this post by Gary Gregory
Gary Gregory wrote:

> How about this as a compromise (thinking aloud):
>
> The (currently imaginary) class VariableFormat holds a Map and defines a
> method VariableFormat#resolve(String name).
>
> [configuration] can subclass the class and override the
> VariableFormat#resolve(String name) to provide its own logic. This would
> allow for the resolve by delegation scenario.
>
> You would "normally" front-load a VariableFormat with a Map.

I'm in two minds about this.

This design is neat, and definitely fits the [lang] scope question (so
long as StrBuilder can use it directly without copying the char[])

However, it has to be said that if VariableResolver is the only
interface we are talking about, then it is little different to
StrTokenizer, so could be considered OK.

Maybe this is a sign that StrTokenizer is too complex? I do think that
we should have a consistent design between StrTokenizer and
VariableFormat though.

(could VariableFormat be called StrFormatter to fit with the rest of the
classes in the package?).

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
> Gary Gregory wrote:
> > How about this as a compromise (thinking aloud):
> >
> > The (currently imaginary) class VariableFormat holds a Map and
defines a
> > method VariableFormat#resolve(String name).
> >
> > [configuration] can subclass the class and override the
> > VariableFormat#resolve(String name) to provide its own logic. This
would

> > allow for the resolve by delegation scenario.
> >
> > You would "normally" front-load a VariableFormat with a Map.
>
> I'm in two minds about this.
>
> This design is neat, and definitely fits the [lang] scope question (so
> long as StrBuilder can use it directly without copying the char[])
>
> However, it has to be said that if VariableResolver is the only
> interface we are talking about, then it is little different to
> StrTokenizer, so could be considered OK.
>
> Maybe this is a sign that StrTokenizer is too complex? I do think that
> we should have a consistent design between StrTokenizer and
> VariableFormat though.
>
> (could VariableFormat be called StrFormatter to fit with the rest of
the
> classes in the package?).

Hm, interesting, allow me to ramble:

What I like about the *Format name is that it relates it to the
java.text.*Format classes, specifically to the MessageFormat class. From
the MessageFormat javadoc:

"MessageFormat provides a means to produce concatenated messages in
language-neutral way."

Our new lang formatter is pretty much like the JRE class in *intent*
(javadoc above), the main difference is that MessageFormat works on
template strings that use the "{indexNumber}" notation, as opposed to
our class which uses the "${variableName}" notation.

So the question I think is: Do we want to provide a MessageFormat
subclass, say "VariableMessageFormat" which works off a Map, etc?

If we do not, then I'd say it is better not to pick a *Format class
name, to make it clear that our class does not work in the java.text
f/w.

I'm not crazy about having all the .text class names starting with "Str"
unless there is a clear reason to do so. The most important feature of
the new class is that it uses /names/ to lookup values in a /Map/ of
some kind.

IMO, the feature should be reflected in the class name, which
"StrFormatter" does not (for me ;-). Based on the name, you cannot tell
the difference b/w StrFormatter and MessageFormat.

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

Oliver Heger
In reply to this post by Gary Gregory
Gary Gregory wrote:

>
> Oliver (or anyone else), would you be willing to take a first cut at
> porting your patch in the Bugzilla ticket referred to earlier to this
> current scheme?
>
> We could then put it in CVS with unit tests and see how it feels to all
> of us once in code form.
>
> Gary
>
Okay, I can do this. I will get to it probably at the weekend (which
will leave you some time to find a consense for the class name ;-)

Oh, one question remains: The interpolation method in the Bugzilla
ticket operates on Objects rather than Strings. This means, if the
source for interpolation contains only a single variable reference, the
return value will be the value of this variable, which can be of
arbitrary type. If the source contains multiple variables and/or static
text, the return value will always be a String with a concatenation of
all these elements.

I think, the most common use case of the class will certainly be string
based interpolation, so the object handling stuff might be unnecessary.
On the other hand, if a result object has been calculated, it is trivial
to convert this into a String by calling its toString() method. The
opposite (converting a String result into a different type) is more
problematic.

What do you think?

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

Gary Gregory
In reply to this post by Gary Gregory
> -----Original Message-----
> From: Oliver Heger [mailto:[hidden email]]
> Sent: Wednesday, June 29, 2005 11:32 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text.Interpolation, on to 2.2
>
> Gary Gregory wrote:
> >
> > Oliver (or anyone else), would you be willing to take a first cut at
> > porting your patch in the Bugzilla ticket referred to earlier to
this
> > current scheme?
> >
> > We could then put it in CVS with unit tests and see how it feels to
all

> > of us once in code form.
> >
> > Gary
> >
> Okay, I can do this. I will get to it probably at the weekend (which
> will leave you some time to find a consense for the class name ;-)
>
> Oh, one question remains: The interpolation method in the Bugzilla
> ticket operates on Objects rather than Strings. This means, if the
> source for interpolation contains only a single variable reference,
the
> return value will be the value of this variable, which can be of
> arbitrary type. If the source contains multiple variables and/or
static
> text, the return value will always be a String with a concatenation of
> all these elements.
>
> I think, the most common use case of the class will certainly be
string
> based interpolation, so the object handling stuff might be
unnecessary.
> On the other hand, if a result object has been calculated, it is
trivial
> to convert this into a String by calling its toString() method. The
> opposite (converting a String result into a different type) is more
> problematic.
>
> What do you think?

When I know that I am always dealing with Strings, it is a bit annoying
to have call toString() on each result. If you really want to keep the
Object version, which seems OK for advanced uses like [configuration],
what about having an "Object resolveObject()" and "String
resolveString()" high level APIs so I can say:

// Uses defaults: ${ and }
VariableFormatter.resolveString(aString, aMap);
VariableFormatter.resolveObject(aString, aMap);

// and maybe even, where the defaults are ${, } and
System.getProperties()
VariableFormatter.resolveString(aString);
// ?

I do not want [configuration] to loose the Object feature *if* it needs
it but I do not want to deal with Object APIs when I know I am dealing
with Strings and we are after all in a .text package.

Hope this helps,
Gary

>
> 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

Oliver Heger-2
Gary Gregory wrote:

>>-----Original Message-----
>>From: Oliver Heger [mailto:[hidden email]]
>>Sent: Wednesday, June 29, 2005 11:32 PM
>>To: Jakarta Commons Developers List
>>Subject: Re: [lang] text.Interpolation, on to 2.2
>>
>>Gary Gregory wrote:
>>    
>>
>>>Oliver (or anyone else), would you be willing to take a first cut at
>>>porting your patch in the Bugzilla ticket referred to earlier to
>>>      
>>>
>this
>  
>
>>>current scheme?
>>>
>>>We could then put it in CVS with unit tests and see how it feels to
>>>      
>>>
>all
>  
>
>>>of us once in code form.
>>>
>>>Gary
>>>
>>>      
>>>
>>Okay, I can do this. I will get to it probably at the weekend (which
>>will leave you some time to find a consense for the class name ;-)
>>
>>Oh, one question remains: The interpolation method in the Bugzilla
>>ticket operates on Objects rather than Strings. This means, if the
>>source for interpolation contains only a single variable reference,
>>    
>>
>the
>  
>
>>return value will be the value of this variable, which can be of
>>arbitrary type. If the source contains multiple variables and/or
>>    
>>
>static
>  
>
>>text, the return value will always be a String with a concatenation of
>>all these elements.
>>
>>I think, the most common use case of the class will certainly be
>>    
>>
>string
>  
>
>>based interpolation, so the object handling stuff might be
>>    
>>
>unnecessary.
>  
>
>>On the other hand, if a result object has been calculated, it is
>>    
>>
>trivial
>  
>
>>to convert this into a String by calling its toString() method. The
>>opposite (converting a String result into a different type) is more
>>problematic.
>>
>>What do you think?
>>    
>>
>
>When I know that I am always dealing with Strings, it is a bit annoying
>to have call toString() on each result. If you really want to keep the
>Object version, which seems OK for advanced uses like [configuration],
>what about having an "Object resolveObject()" and "String
>resolveString()" high level APIs so I can say:
>
>// Uses defaults: ${ and }
>VariableFormatter.resolveString(aString, aMap);
>VariableFormatter.resolveObject(aString, aMap);
>
>// and maybe even, where the defaults are ${, } and
>System.getProperties()
>VariableFormatter.resolveString(aString);
>// ?
>
>I do not want [configuration] to loose the Object feature *if* it needs
>it but I do not want to deal with Object APIs when I know I am dealing
>with Strings and we are after all in a .text package.
>
>Hope this helps,
>Gary
>
>  
>
Yes, the base method returns an Object, and there are several
convenience methods that cast this result to a String. This is what I
had in mind, too.

Thanks,
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

Gary Gregory
In reply to this post by Gary Gregory
Oliver wrote:

> Yes, the base method returns an Object, and there are several
> convenience methods that cast this result to a String. This is what I
> had in mind, too.

Oliver,

Would you be willing to have a go at creating these classes for lang?

Thanks,
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
Gary Gregory wrote:

>Oliver,
>
>Would you be willing to have a go at creating these classes for lang?
>
>Thanks,
>Gary
>
>  
>
A first implementation can be found at the new BZ ticket 35588:
http://issues.apache.org/bugzilla/show_bug.cgi?id=35588

Comments are welcome!
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

Gary Gregory
In reply to this post by Gary Gregory
Thank you Oliver. I'll be taking a look over the weekend.

Gary

> -----Original Message-----
> From: Oliver Heger [mailto:[hidden email]]
> Sent: Saturday, July 02, 2005 11:42 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] text.Interpolation, on to 2.2
>
> Gary Gregory wrote:
>
> >Oliver,
> >
> >Would you be willing to have a go at creating these classes for lang?
> >
> >Thanks,
> >Gary
> >
> >
> >
> A first implementation can be found at the new BZ ticket 35588:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35588
>
> Comments are welcome!
> 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

Simon Kitching
In reply to this post by Gary Gregory
On Wed, 2005-06-29 at 20:24 -0400, Gary Gregory wrote:

> What I like about the *Format name is that it relates it to the
> java.text.*Format classes, specifically to the MessageFormat class. From
> the MessageFormat javadoc:
>
> "MessageFormat provides a means to produce concatenated messages in
> language-neutral way."
>
> Our new lang formatter is pretty much like the JRE class in *intent*
> (javadoc above), the main difference is that MessageFormat works on
> template strings that use the "{indexNumber}" notation, as opposed to
> our class which uses the "${variableName}" notation.
>
> So the question I think is: Do we want to provide a MessageFormat
> subclass, say "VariableMessageFormat" which works off a Map, etc?
>
> If we do not, then I'd say it is better not to pick a *Format class
> name, to make it clear that our class does not work in the java.text
> f/w.
>
> I'm not crazy about having all the .text class names starting with "Str"
> unless there is a clear reason to do so. The most important feature of
> the new class is that it uses /names/ to lookup values in a /Map/ of
> some kind.
>
> IMO, the feature should be reflected in the class name, which
> "StrFormatter" does not (for me ;-). Based on the name, you cannot tell
> the difference b/w StrFormatter and MessageFormat.

I am concerned about the parallels being drawn between MessageFormat and
(proposed) VariableFormat. While they are both about combining messages
with variables, they actually work in opposite ways. MessageFormat is
based on defining a template "My {0} is {1}.", then evaulating this for
different values of {0} and {1}. The (proposed) VariableFormat is based
on defining a source of variable info (Map), then evaulating different
template strings against that map. I think the current VariableFormat
approach is the right approach for mapped data but this difference
implies that care should be taken when drawing any parallels between
these classes.

I think this is what Gary meant above; that if this class cannot be
implemented as a subclass of java.text.MessageFormat (or at least a
subclass of java.text.Format) then it shouldn't have Format in the name.
And it doesn't seem that it can (or should) do this, so I would like to
see whatever solution is agreed on avoid the name "Format".

I am also concerned about the complexity of the VariableFormat API; the
class has something like a dozen non-private methods. I would be very
keen to see it split into an interface + implementation so people could
provide alternative implementations (like java.text.Format is the base
for multiple formatters).

The VariableFormat class has also done away with the ability to have
multiple sources of data which was present in MappedMessageFormat. This
functionality is not critical, but it's nice.

On the other hand the repeated substitution with cycle detection feature
is a very nice addition.

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.

All these comments are a little rushed; I'm trying to juggle several
things at once at the moment so sorry for that. I'll try to spend a
little more time on this soon.

Regards,

Simon


---------------------------------------------------------------------
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: Simon Kitching [mailto:[hidden email]]
> Sent: Tuesday, July 05, 2005 9:38 PM
> To: Jakarta Commons Developers List
> Subject: RE: [lang] text.Interpolation, on to 2.2
>
> On Wed, 2005-06-29 at 20:24 -0400, Gary Gregory wrote:
>
> > What I like about the *Format name is that it relates it to the
> > java.text.*Format classes, specifically to the MessageFormat class.
From
> > the MessageFormat javadoc:
> >
> > "MessageFormat provides a means to produce concatenated messages in
> > language-neutral way."
> >
> > Our new lang formatter is pretty much like the JRE class in *intent*
> > (javadoc above), the main difference is that MessageFormat works on
> > template strings that use the "{indexNumber}" notation, as opposed
to

> > our class which uses the "${variableName}" notation.
> >
> > So the question I think is: Do we want to provide a MessageFormat
> > subclass, say "VariableMessageFormat" which works off a Map, etc?
> >
> > If we do not, then I'd say it is better not to pick a *Format class
> > name, to make it clear that our class does not work in the java.text
> > f/w.
> >
> > I'm not crazy about having all the .text class names starting with
"Str"
> > unless there is a clear reason to do so. The most important feature
of
> > the new class is that it uses /names/ to lookup values in a /Map/ of
> > some kind.
> >
> > IMO, the feature should be reflected in the class name, which
> > "StrFormatter" does not (for me ;-). Based on the name, you cannot
tell
> > the difference b/w StrFormatter and MessageFormat.
>
> I am concerned about the parallels being drawn between MessageFormat
and
> (proposed) VariableFormat. While they are both about combining
messages
> with variables, they actually work in opposite ways. MessageFormat is
> based on defining a template "My {0} is {1}.", then evaulating this
for
> different values of {0} and {1}. The (proposed) VariableFormat is
based
> on defining a source of variable info (Map), then evaulating different
> template strings against that map. I think the current VariableFormat
> approach is the right approach for mapped data but this difference
> implies that care should be taken when drawing any parallels between
> these classes.

My idea (see [POLL] email and express yourself ;-) would be to keep and
rename VariableFormat and remove the two other classes: Interpolation
and MappedMessageFormat.

> I think this is what Gary meant above; that if this class cannot be
> implemented as a subclass of java.text.MessageFormat (or at least a
> subclass of java.text.Format) then it shouldn't have Format in the
name.
> And it doesn't seem that it can (or should) do this, so I would like
to
> see whatever solution is agreed on avoid the name "Format".

Yes, I will rename VariableFormat to... VariableFormatter for now.

> I am also concerned about the complexity of the VariableFormat API;
the
> class has something like a dozen non-private methods. I would be very
> keen to see it split into an interface + implementation so people
could
> provide alternative implementations (like java.text.Format is the base
> for multiple formatters).

The original code from Oliver did have an interface to resolve
variables. The discussion on this list had some in favor of a simpler
solution: just one class that can be subclassed. In particular, some had
the impression that Oliver's original code was too framework-like. The
current one class solution still solves Oliver's requirements for
[configuration]. I am open to going back to Oliver's use of an interface
to resolve variable, which I thought was really nice.

> The VariableFormat class has also done away with the ability to have
> multiple sources of data which was present in MappedMessageFormat.
This
> functionality is not critical, but it's nice.

A subclass can resolve variables as it sees fit. The issue in my mind,
is that a subclass creates tight coupling, while Oliver's original
VariableResolver interface created a more flexible solution, albeit,
more "framework-like", which some folks disliked.

> On the other hand the repeated substitution with cycle detection
feature
> is a very nice addition.

Yes, I like that.

>
> 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?

Gary

>
> All these comments are a little rushed; I'm trying to juggle several
> things at once at the moment so sorry for that. I'll try to spend a
> little more time on this soon.
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> 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

Stephen Colebourne
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[])

b) we have lost the ability to have multiple substitutions

c) we have added a complex escaping mechanism

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

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.

Stephen

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

123