Almost done on text package - StrSubstitutor needs replace methods
taking a StringBuffer (as adding them later causes overloading issues as
per StringBuffer itself from JDK1.3 to 1.4)
Stephen
Henri Yandell wrote:
On 8/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
On 8/4/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote:
Well I'd love to see this method in 2.2 because I think it does make any
API visible to the user and doesn't bloat the
interface with too many new methods.
Any other
Henri Yandell wrote:
On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote:
Well I'd love to see this method in 2.2 because I think it does make any
API visible to the user and doesn't bloat the
interface with too many new methods.
Any other thoughts?
Just that now that Attributes 2.2 is out, I'm
On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote:
Well I'd love to see this method in 2.2 because I think it does make any
API visible to the user and doesn't bloat the
interface with too many new methods.
Any other thoughts?
Just that now that Attributes 2.2 is out, I'm ready to start cutting
Henri Yandell schrieb:
On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote:
Well I'd love to see this method in 2.2 because I think it does make any
API visible to the user and doesn't bloat the
interface with too many new methods.
Any other thoughts?
Just that now that Attributes 2.2 is out,
Make a new one - unless you're arguing for the change to be in 2.2;
then keep it going on this thread.
Hen
On 8/2/06, Tom Schindl [EMAIL PROTECTED] wrote:
Where should I put my feature request should I:
- append it to VariableFormatter's-Jira-Entry
- create a new Jira-Entry for StrSubstitutor
Well I'd love to see this method in 2.2 because I think it does make any
API visible to the user and doesn't bloat the
interface with too many new methods.
Any other thoughts?
Tom
Henri Yandell wrote:
Make a new one - unless you're arguing for the change to be in 2.2;
then keep it going on
-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Monday, July 31, 2006 11:30 PM
To: Jakarta Commons Developers List; Stephen Colebourne
Subject: Re: [lang] VariableFormatter - pre 2.2
On 7/23/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
I have reworked the VariableFormatter class along
Stephen Colebourne wrote:
For example There were ${number} characters, would return the
object matching the ${number} substitution, and dropping the rest of
the text!
Perhaps you can point to an exact use case?
Oliver Heger wrote:
Your analysis is correct. The idea was that you can have
On 8/2/06, Gary Gregory [EMAIL PROTECTED] wrote:
Hello All:
I think the argument for the name change I am hearing is: we are not
formatting a la printf but we are replacing markers with values (and not
formatting those values). Is that right? If that is the case, a
Substitutor name is better.
Henri Yandell wrote:
On 8/2/06, Gary Gregory [EMAIL PROTECTED] wrote:
I think in some places it was to avoid clash with JDK 1.5.
StringBuilder I presume being the one.
(I sent a mail earlier, but its not arrived)
But yes, this is the key point. StrBuilder is a pre JDK5 version of
On 7/23/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
I have reworked the VariableFormatter class along the lines that I was
thinking. I have committed it as StrSubstitutor so it doesn't clash for the
moment and so it can be easiy reviewed.
This version does not have a separate parser
Hi,
Looks good to me. Maybe for 2.3 this patch could provide
MessageFormatting like proposed before without bloating the API. Does
this now mean that VariableFormatter is gone? I like the nameing
StrSubstitutor better.
Tom
Henri Yandell schrieb:
On 7/23/06, Stephen Colebourne [EMAIL PROTECTED]
For my part
On 8/1/06, Oliver Heger [EMAIL PROTECTED] wrote:
+1 for the name StrSubstitutor.
I'm ambivalent on the name. I've always called this introspecting, but
we killed that name a while back so I'll take anything.
Well, I guess I have no chance to convince you to get back to
Stephen Colebourne wrote:
Oliver Heger wrote:
+1 for the name StrSubstitutor.
:-)
Well, I guess I have no chance to convince you to get back to Object
as result type for the resolver interface? Hm, for [configuration] I
can probably live with this, but it may cause unnecessary conversions.
For example There were ${number} characters, would return the object
matching the ${number} substitution, and dropping the rest of the text!
Perhaps you can point to an exact use case?
Oliver Heger wrote:
Your analysis is correct. The idea was that you can have specialized
resolver
I have reworked the VariableFormatter class along the lines that I was
thinking. I have committed it as StrSubstitutor so it doesn't clash for the
moment and so it can be easiy reviewed.
This version does not have a separate parser class, but still supports
escaping, and matchers for
I have reworked the VariableFormatter class along the lines that I was
thinking. I have committed it as StrSubstitutor so it doesn't clash for
the moment and so it can be easiy reviewed.
This version does not have a separate parser class, but still supports
escaping, and matchers for
Henri Yandell schrieb:
This is all that's left in 2.2 before an RC can be built.
On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
To: Jakarta Commons Developers List
Subject: Re: [lang] VariableFormatter - pre 2.2
This is all that's left in 2.2 before an RC can be built.
On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm
Henri Yandell wrote:
This is all that's left in 2.2 before an RC can be built.
On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't
On 7/21/06, Oliver Heger [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
This is all that's left in 2.2 before an RC can be built.
On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record
This is all that's left in 2.2 before an RC can be built.
On 7/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO.
On 7/7/06, Oliver Heger [EMAIL PROTECTED] wrote:
Stephen Colebourne wrote:
snip/
Oliver Heger wrote:
Fine with me, but could the return value of lookup be Object instead
of String? Especially if you want to use this interface in other
areas, you might need more freedom. If only String
Stephen Colebourne wrote:
snip/
Oliver Heger wrote:
Fine with me, but could the return value of lookup be Object instead
of String? Especially if you want to use this interface in other
areas, you might need more freedom. If only String processing needs
to be performed, the returned
Stephen Colebourne wrote:
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
At a minimum, I'd like to see
PROTECTED]
Sent: Wednesday, July 05, 2006 5:07 PM
To: Jakarta Commons Developers List
Subject: [lang] VariableFormatter - pre 2.2
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't
Gary Gregory wrote:
At a minimum, I'd like to see MapVariableResolver packge scoped.
Looking at the message thread:
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg78697.html
It seems that another proposal being discussed back in April was to make
some classes /easier/ to reuse
Henri Yandell wrote:
Anyone know of any half-finished code in there at the moment?
I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
At a minimum, I'd like to see MapVariableResolver packge scoped.
29 matches
Mail list logo
