[
https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537981
]
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 one?
* 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).
Noted.
* 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.
http://martinfowler.com/bliki/FluentInterface.html
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 purposely.
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.
-Matt
> Add ExtendedMessageFormat to org.apache.commons.lang.text
> ---------------------------------------------------------
>
> Key: LANG-362
> URL: https://issues.apache.org/jira/browse/LANG-362
> 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@ (
> http://mail-archives.apache.org/mod_mbox/commons-dev/200710.mbox/[EMAIL
> PROTECTED] ); 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.
