Re: [lang] VariableFormatter issues
snip The implementation in the ticket subclasses VariableFormatter, why not subclass just MapVariableResolver only? Because of the above mentionned bloated API if you want to turn it on/off in VariableFormatter. I think part of the problem is that many method signatures expect a Map and convert this automatically into a MapVariableResolver (e.g. constructors of VariableFormatter, static replace() methods). This is convenient for the users that only need the default functionality, but makes it hard to use a different VariableResolver implementation. Shouldn't we at least have static replace() methods that take a VariableResolver as argument? Then a caller can decide if he/she wants a default or a formatting enabled resolver. Yeah. I agree 100% with you Oliver having such a method and adding an boolean attribute to MapVariableResolver to turn on/off the feature would be sufficient. Tom signature.asc Description: OpenPGP digital signature
Re: [lang] VariableFormatter issues
Tom Schindl wrote:
Gary Gregory wrote:
Hello:
I wonder if in the interest of getting version 2.2 out the door we
should keep VariableFormatter as-is. Anyone who likes the subclass can
obviously use it. If the feature is easy to add, we don't have to
discuss the following for post-2.2:
- Does the VariableFormatterWithFormating functionality belong in
VariableFormatter or should it be a subclass.
- It seems like we could also extend the current ${} syntax to include
the VariableFormatterWithFormating feature. Where this gets tricky and
could become difficult is if we cannot reuse MessageFormat.format.
Tom (and all):
Have you considered changing VariableFormatter itself to provide the
feature?
Yes but I thought if you want to turn on/off variable formatting (e.g.
because of performance issues) the API would get too bloated, you need
to duplicate all static functions, wouldn't you?
Would changing MapVariableResolver only do the trick?
Yes, I think so but I wasn't sure about the side-effects.
The implementation in the ticket subclasses VariableFormatter, why not
subclass just MapVariableResolver only?
Because of the above mentionned bloated API if you want to turn it
on/off in VariableFormatter.
I think part of the problem is that many method signatures expect a Map
and convert this automatically into a MapVariableResolver (e.g.
constructors of VariableFormatter, static replace() methods). This is
convenient for the users that only need the default functionality, but
makes it hard to use a different VariableResolver implementation.
Shouldn't we at least have static replace() methods that take a
VariableResolver as argument? Then a caller can decide if he/she wants a
default or a formatting enabled resolver.
Oliver
snip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter issues
Gary Gregory wrote: 1) First enhancement request: #36873. Adds MessageFormat like format patterns. It's an enhancement, seems like a pretty good one to me as it is an enhancement that builds on the JDK and not a new feature. How does this sit on people's slippery slopes? OTOH, the class VariableFormatter is named as such *because* it is not a Format subclass and was not intended to be. So providing Format features via a subclass to VariableFormatter is clean in the sense that we are not mixing things up but not really what I had in mind (that's the great part about OS). OTOH (the OOH), if we really think this is a fantastic feature, we should consider if it should be better integrated than with a subclass. I would like to see any changes here properly integrated if its going to be added. I haven't studied the change in too much detail, but I don't see it as an independent piece of functionality. I would also want to avoid making the inner classes public if possible. BTW, lots of inner classes make the jar file quite a lot bigger. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] VariableFormatter issues
Gary Gregory wrote:
Hello:
I wonder if in the interest of getting version 2.2 out the door we
should keep VariableFormatter as-is. Anyone who likes the subclass can
obviously use it. If the feature is easy to add, we don't have to
discuss the following for post-2.2:
- Does the VariableFormatterWithFormating functionality belong in
VariableFormatter or should it be a subclass.
- It seems like we could also extend the current ${} syntax to include
the VariableFormatterWithFormating feature. Where this gets tricky and
could become difficult is if we cannot reuse MessageFormat.format.
Tom (and all):
Have you considered changing VariableFormatter itself to provide the
feature?
Yes but I thought if you want to turn on/off variable formatting (e.g.
because of performance issues) the API would get too bloated, you need
to duplicate all static functions, wouldn't you?
Would changing MapVariableResolver only do the trick?
Yes, I think so but I wasn't sure about the side-effects.
The implementation in the ticket subclasses VariableFormatter, why not
subclass just MapVariableResolver only?
Because of the above mentionned bloated API if you want to turn it
on/off in VariableFormatter.
To make the code more reusable we should be open to making the inner
classes stand alone.
That would be a great thing to have.
Gary
I think adding this formatting to VariableFormatter makes it more
useable e.g. for displaying debugging messages than it would be now.
Tom
signature.asc
Description: OpenPGP digital signature
Re: [lang] VariableFormatter issues
Gary Gregory wrote:
Hello:
I wonder if in the interest of getting version 2.2 out the door we
should keep VariableFormatter as-is. Anyone who likes the subclass can
obviously use it. If the feature is easy to add, we don't have to
discuss the following for post-2.2:
- Does the VariableFormatterWithFormating functionality belong in
VariableFormatter or should it be a subclass.
- It seems like we could also extend the current ${} syntax to include
the VariableFormatterWithFormating feature. Where this gets tricky and
could become difficult is if we cannot reuse MessageFormat.format.
Tom (and all):
Have you considered changing VariableFormatter itself to provide the
feature?
Yes but I thought if you want to turn on/off variable formatting (e.g.
because of performance issues) the API would get too bloated, you need
to duplicate all static functions, wouldn't you?
Would changing MapVariableResolver only do the trick?
Yes, I think so but I wasn't sure about the side-effects.
The implementation in the ticket subclasses VariableFormatter, why not
subclass just MapVariableResolver only?
Because of the above mentionned bloated API if you want to turn it
on/off in VariableFormatter.
To make the code more reusable we should be open to making the inner
classes stand alone.
That would be a great thing to have.
Gary
I think adding this formatting to VariableFormatter makes it more
useable e.g. for displaying debugging messages than it would be now.
Tom
signature.asc
Description: PGP signature
signature.asc
Description: OpenPGP digital signature
Re: [lang] VariableFormatter issues
Gary Gregory wrote: -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, April 24, 2006 12:12 AM To: Jakarta Commons Developers List Subject: [lang] VariableFormatter issues Our favourite 'will this become a templating language' class. Two issues to ask questions about: 1) First enhancement request: #36873. Adds MessageFormat like format patterns. It's an enhancement, seems like a pretty good one to me as it is an enhancement that builds on the JDK and not a new feature. How does this sit on people's slippery slopes? This is interesting and slippery. Since the submitted code uses MessageFormat.format, we are not inventing a language, just accessing a JRE feature. OTOH, the class VariableFormatter is named as such *because* it is not a Format subclass and was not intended to be. So providing Format features via a subclass to VariableFormatter is clean in the sense that we are not mixing things up but not really what I had in mind (that's the great part about OS). OTOH (the OOH), if we really think this is a fantastic feature, we should consider if it should be better integrated than with a subclass. I like VariableFormatter the way it is. So I am neutral as to using the submitted code. If we do use VariableFormatterWithFormating, could we consider better class name? Well I like it (maybe because I've submitted it) and use it frequently in my source codes. I wasn't really happy with the name too, still in my idea you don't need a sub-class a better idea would be a flag passed and turns on/off formatting but on the other hand this would maybe blow up the numer of API-Functions. Tom signature.asc Description: OpenPGP digital signature
RE: [lang] VariableFormatter issues
Hello:
I wonder if in the interest of getting version 2.2 out the door we
should keep VariableFormatter as-is. Anyone who likes the subclass can
obviously use it. If the feature is easy to add, we don't have to
discuss the following for post-2.2:
- Does the VariableFormatterWithFormating functionality belong in
VariableFormatter or should it be a subclass.
- It seems like we could also extend the current ${} syntax to include
the VariableFormatterWithFormating feature. Where this gets tricky and
could become difficult is if we cannot reuse MessageFormat.format.
Tom (and all):
Have you considered changing VariableFormatter itself to provide the
feature?
Would changing MapVariableResolver only do the trick?
The implementation in the ticket subclasses VariableFormatter, why not
subclass just MapVariableResolver only?
To make the code more reusable we should be open to making the inner
classes stand alone.
Gary
Sent: Tuesday, April 25, 2006 7:05 AM
To: Jakarta Commons Developers List
Subject: Re: [lang] VariableFormatter issues
Gary Gregory wrote:
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Monday, April 24, 2006 12:12 AM
To: Jakarta Commons Developers List
Subject: [lang] VariableFormatter issues
Our favourite 'will this become a templating language' class.
Two issues to ask questions about:
1) First enhancement request: #36873. Adds MessageFormat like format
patterns. It's an enhancement, seems like a pretty good one to me as
it is an enhancement that builds on the JDK and not a new feature.
How
does this sit on people's slippery slopes?
This is interesting and slippery. Since the submitted code uses
MessageFormat.format, we are not inventing a language, just
accessing
a JRE feature.
OTOH, the class VariableFormatter is named as such *because* it is
not a
Format subclass and was not intended to be. So providing Format
features via a subclass to VariableFormatter is clean in the sense
that
we are not mixing things up but not really what I had in mind
(that's
the great part about OS). OTOH (the OOH), if we really think this is
a
fantastic feature, we should consider if it should be better
integrated
than with a subclass.
I like VariableFormatter the way it is. So I am neutral as to using
the
submitted code. If we do use VariableFormatterWithFormating, could
we
consider better class name?
Well I like it (maybe because I've submitted it) and use it frequently
in my source codes. I wasn't really happy with the name too, still in
my
idea you don't need a sub-class a better idea would be a flag passed
and
turns on/off formatting but on the other hand this would maybe blow up
the numer of API-Functions.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[lang] VariableFormatter issues
Our favourite 'will this become a templating language' class. Two issues to ask questions about: 1) First enhancement request: #36873. Adds MessageFormat like format patterns. It's an enhancement, seems like a pretty good one to me as it is an enhancement that builds on the JDK and not a new feature. How does this sit on people's slippery slopes? 2) Any idea what the status of the 35588 issue is? Looks like it was all done with just some minor OT Clover stuff. Any reason to keep this open? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] VariableFormatter issues
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Monday, April 24, 2006 12:12 AM To: Jakarta Commons Developers List Subject: [lang] VariableFormatter issues Our favourite 'will this become a templating language' class. Two issues to ask questions about: 1) First enhancement request: #36873. Adds MessageFormat like format patterns. It's an enhancement, seems like a pretty good one to me as it is an enhancement that builds on the JDK and not a new feature. How does this sit on people's slippery slopes? This is interesting and slippery. Since the submitted code uses MessageFormat.format, we are not inventing a language, just accessing a JRE feature. OTOH, the class VariableFormatter is named as such *because* it is not a Format subclass and was not intended to be. So providing Format features via a subclass to VariableFormatter is clean in the sense that we are not mixing things up but not really what I had in mind (that's the great part about OS). OTOH (the OOH), if we really think this is a fantastic feature, we should consider if it should be better integrated than with a subclass. I like VariableFormatter the way it is. So I am neutral as to using the submitted code. If we do use VariableFormatterWithFormating, could we consider better class name? 2) Any idea what the status of the 35588 issue is? Looks like it was all done with just some minor OT Clover stuff. Any reason to keep this open? I was trying to get 100% code coverage with Clover. I think you can close this one. In my perfect world, any new features and patches would get 100% code coverage. Gary Hen - 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]
