commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton (JIRA)" <>
Subject [jira] Commented: (LANG-362) Add ExtendedMessageFormat to org.apache.commons.lang.text
Date Mon, 04 Feb 2008 04:29:08 GMT


Niall Pemberton commented on LANG-362:

You're right it hadn't hit my radar about toPattern() reconstructing the pattern from internal
state and so my suggestion reflects only half the equation, i.e. pattern-->Format and not

The first thought I have about this is that one option would be to only support toPattern()
for 1) existing MessageFormat compatiblity (i.e. the four "standard" built in formats) and
2) those configured through the pattern (i.e. not "non-standard" formats configured using
the setFormat() methods). I believe this would be fairly straight forward to do and since
EMF is providing a mechanism for using any format thru' the pattern then the use of setFormat()
methods becomes unnecessary. 

Having said that even if full toPattern() support is an absolute must I still think the use
of "meta formats" and the current implementation over-complicates things and my thinking goes
along the following lines:

 - Using a meta "Format" implementation for the pattern<-->Format conversion is confusing
in itself. I think this is where my Factory suggestion has merit since the idea of registering
a "format factory" and then EMF looking-up a registered factory to create a Format is much
more straight forward concept for users to grasp.

 - The current implementation does this kind of "look-up" (using NameKeyMetaFormat) but in
an overcomplicated way - by creating an aggregated MultiFormat which tries to parse using
delegated NameKeyMetaFormat which in turn delegates again if the format itself has arguments.
Since the FormatElement part of message format's pattern is always {index, FormatType, args}
then why have every meta-format repeatedly parse that info trying to match - my suggestion
involved EMF extracting out the FormatType, looking up a registered factory for it and if
found the factory then just parsing the arguments component. Surely this is simpler and less
error prone than having to repeat the whole parsing of the FormatElement in every meta format?

 - If I didn't convice you with my earlier reasoning about whether full toPattern() support
is really required then I think this can also be supported using the factory concept. It would
reguire the "registry" to be more than a simple Map (i.e. be able to lookup a factory based
on a Format, as well as name) and the FormatFactory would need additional method(s) to support
re-creating the pattern - but I think that is doable as well.

Anyway I'm not wedded to my proposal (I generally try not to just throw out criticism since
IMO what counts at the ASF is not talking, but doing) and have no problem it being dismissed
- but I'm not convinced that what is there currently should be included in an official release.
I think the concept is great, but supporting the code and users for this I think will be a
headache that we regret down the line.

> 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, 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