> From: Simon Kitching [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 05, 2005 9:38 PM > To: Jakarta Commons Developers List > Subject: RE: [lang] text.Interpolation, on to 2.2 > > On Wed, 2005-06-29 at 20:24 -0400, Gary Gregory wrote: > > > What I like about the *Format name is that it relates it to the > > java.text.*Format classes, specifically to the MessageFormat class. From > > the MessageFormat javadoc: > > > > "MessageFormat provides a means to produce concatenated messages in > > language-neutral way." > > > > Our new lang formatter is pretty much like the JRE class in *intent* > > (javadoc above), the main difference is that MessageFormat works on > > template strings that use the "{indexNumber}" notation, as opposed to > > our class which uses the "${variableName}" notation. > > > > So the question I think is: Do we want to provide a MessageFormat > > subclass, say "VariableMessageFormat" which works off a Map, etc? > > > > If we do not, then I'd say it is better not to pick a *Format class > > name, to make it clear that our class does not work in the java.text > > f/w. > > > > I'm not crazy about having all the .text class names starting with "Str" > > unless there is a clear reason to do so. The most important feature of > > the new class is that it uses /names/ to lookup values in a /Map/ of > > some kind. > > > > IMO, the feature should be reflected in the class name, which > > "StrFormatter" does not (for me ;-). Based on the name, you cannot tell > > the difference b/w StrFormatter and MessageFormat. > > I am concerned about the parallels being drawn between MessageFormat and > (proposed) VariableFormat. While they are both about combining messages > with variables, they actually work in opposite ways. MessageFormat is > based on defining a template "My {0} is {1}.", then evaulating this for > different values of {0} and {1}. The (proposed) VariableFormat is based > on defining a source of variable info (Map), then evaulating different > template strings against that map. I think the current VariableFormat > approach is the right approach for mapped data but this difference > implies that care should be taken when drawing any parallels between > these classes.
My idea (see [POLL] email and express yourself ;-) would be to keep and rename VariableFormat and remove the two other classes: Interpolation and MappedMessageFormat. > I think this is what Gary meant above; that if this class cannot be > implemented as a subclass of java.text.MessageFormat (or at least a > subclass of java.text.Format) then it shouldn't have Format in the name. > And it doesn't seem that it can (or should) do this, so I would like to > see whatever solution is agreed on avoid the name "Format". Yes, I will rename VariableFormat to... VariableFormatter for now. > I am also concerned about the complexity of the VariableFormat API; the > class has something like a dozen non-private methods. I would be very > keen to see it split into an interface + implementation so people could > provide alternative implementations (like java.text.Format is the base > for multiple formatters). The original code from Oliver did have an interface to resolve variables. The discussion on this list had some in favor of a simpler solution: just one class that can be subclassed. In particular, some had the impression that Oliver's original code was too framework-like. The current one class solution still solves Oliver's requirements for [configuration]. I am open to going back to Oliver's use of an interface to resolve variable, which I thought was really nice. > The VariableFormat class has also done away with the ability to have > multiple sources of data which was present in MappedMessageFormat. This > functionality is not critical, but it's nice. A subclass can resolve variables as it sees fit. The issue in my mind, is that a subclass creates tight coupling, while Oliver's original VariableResolver interface created a more flexible solution, albeit, more "framework-like", which some folks disliked. > On the other hand the repeated substitution with cycle detection feature > is a very nice addition. Yes, I like that. > > The source of values for the VariableFormat class is only allowed to be > a Map. I'm not sure if people will want other types of data sources. Yes > the resolveVariable method does allow customisation via subclassing but > the fact that the "default" source is a map is very obviously exposed > via the class API. Well, should we go back to the interface approach? Gary > > All these comments are a little rushed; I'm trying to juggle several > things at once at the moment so sorry for that. I'll try to spend a > little more time on this soon. > > Regards, > > Simon > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
