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