[
https://issues.apache.org/jira/browse/LANG-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565260#action_12565260
]
niallp edited comment on LANG-362 at 2/3/08 8:31 PM:
--------------------------------------------------------------
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-to-Format and not Format-to-pattern.
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.
was (Author: niallp):
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 Format-->pattern.
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: 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: DateFormatFactory.java, extendedMessageFormat.patch.txt,
> extendedMessageFormat.patch.txt, ExtendedMessageFormat2.java,
> FormatFactory.java
>
>
> 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.
