Hm, I did not realize that being to f/w-ish was an issue, which is fine and seems clear now.
How about this as a compromise (thinking aloud): The (currently imaginary) class VariableFormat holds a Map and defines a method VariableFormat#resolve(String name). [configuration] can subclass the class and override the VariableFormat#resolve(String name) to provide its own logic. This would allow for the resolve by delegation scenario. You would "normally" front-load a VariableFormat with a Map. Oliver, would you consider this workable for [configuration]? Gary -----Original Message----- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 29, 2005 8:47 AM To: Jakarta Commons Developers List Subject: Re: [lang] text.Interpolation, on to 2.2 Gary Gregory wrote: > Hi & wait a sec, you cannot just "let the other methods unimplemented", > the code will not compile. All interface methods must be implemented, > the bodies of void methods can be empty, others and can return nulls and > 0's or throw exceptions, sure, but that seems confusing. By unimplemented I meant throwing an UnsupportedOperationException or NotImplementedException for example, or returning a null value as you suggested. > It seems simpler to have an interface with one method than to explain > that the resolver is a Map, but not really, and that, today, only this > here methods needs to be implemented. Or am I missing something? I think it would be simpler to use a standard interface rather than introducing a new one that very few people will use. It looks to me like a good compromise between simplicity and an approach that may look a bit too "framework-ish" that Simon was concerned about. Emmanuel Bourg --------------------------------------------------------------------- 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]
