commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Benson (JIRA)" <>
Subject [jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
Date Fri, 26 Oct 2007 14:57:50 GMT


Matt Benson commented on LANG-362:

* Ack, lots of new classes in text. I wonder if commons.lang.format would be a tidier place.

This was the main reason I wanted to have some older [lang] hands take a look.  Would CompositeFormat
then be deprecated, copied to the new package, and have the old class extend the re-packaged

* MetaFormat seems to be a crux interface, but the javadoc is tiny. 

I can add a little clarification there.

* reverse(Map) confused me - my first thought was 'HashMaps don't have order'. Invert is a
better name (and you use it in the javadoc). 


* MultiFormat is a completely separate class - we should have a different JIRA item for that.
I feel that this has come up before, but maybe I'm thinking of CompositeFormat. Needs a unit
test focused on this, rather than the hook in in MessageFormatExtension [assuming I'm right
and this is a class that can be used separately from the rest of it]. 

Yeah, CompositeFormat uses one delegate to parse, another to Format.  MultiFormat iterates
each operation over the first delegate that can perform it successfully.  I can certainly
add this as a separate issue and add its own tests.  :)

* MultiFormat.Builder - what does 'fluent interface' mean? And what are the Builder classes
for in this and NameKeyedMetaFormat, nothing uses them - until I looked in the Tests and saw
them using them - not a common pattern for Lang and definitely something that if we keep it
would need strong documentation.

I may have exaggerated a bit; I would consider the *Builders in oacl.builder to be closer
to being true fluent interfaces; these Builders serve similar purposes by allowing chained
method calls to quickly slap together an instance of the class they are intended to build.
 They're not strictly necessary, obviously.

* DefaultMetaFormatFactory - This makes me think there is a way of replacing it with another.
Is there? If not, is the Default necessary? 

The intent of the classname is to convey that this class provides static factory methods to
generate, for the default or a specific Locale, a metaFormat that, when used by ExtendedMessageFormat,
will produce behavior identical to java.text.MessageFormat.  So it's a factory for a default
metaformat.  Not a default metaformat-factory, see?  Any suggestions on how better to express
the intent in the name?  Or I could move this stuff to static methods directly on ExtendedMessageFormat.

* Various 'non-Javadoc' bits in there. IDE spam? 

Considering most of these are probably methods overridden from classes in java.text, I probably
should replace these by actual javadoc comments.  For methods overridden on other classes
for which source is available--and for which there are no potential IP issues in allowing
inherited comments--I like allowing these to remain as they signify the javadoc has been omitted

Thanks for your input, Henri!  I will work on the simpler issues ASAP, and postpone the others
until we (and anyone else who cares to jump in) discuss it a little further.


> Add ExtendedMessageFormat to org.apache.commons.lang.text
> ---------------------------------------------------------
>                 Key: LANG-362
>                 URL:
>             Project: Commons Lang
>          Issue Type: New Feature
>            Reporter: Matt Benson
>            Assignee: Matt Benson
>            Priority: Minor
>             Fix For: 2.4
>         Attachments: extendedMessageFormat.patch.txt
> Discussed on dev@ (
); adding here for tracking purposes and in case anyone has any serious objections to my implementation.
 Patch forthcoming...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message