Dear [convert] Members and Contributors As discussed, Goldman Sachs has allowed me to release the core of my conversion framework under Apache License 2.0. Goldman Sachs has already signed Apache Foundation's "Contributor License Agreement" as part of an earlier contribution to HttpClient.
I've renamed the packages and classes to be in line with conventions used in [convert]. This way if Stephen finds it appropriate he can easily add the implementation to CVS as option "convert3". I did not include unit tests in my rip-out-and-rename effort, I will gladly do so on request. I also did not include any classes that had external dependencies. The small amount of code that remains should demonstrate how the concept fits together! You'll notice that the proposed Conversion.convert() takes only one parameter as discussed earlier. You'll also notice that ConversionRegistry.convert() takes only one "key" parameter instead of "from type" / "to type" pair. This came about for two reasons. First, I noticed that application code concerned with conversion in each direction (say String->Object vs. Object->String) was typically disjoint. It was easy to use two single-keyed instances of ConversionRegistry instead of one pair-keyed. Second, by ridding the key of semantic baggage one can reuse ConversionRegistry in a different pattern, for example associating a Conversion with a Method or property name rather than type. In any case, ConversionRegistry is not the only possible manager semantic. A two-keyed implementation perhaps with a different mapping algorithms can be implemented where required. I hope that the attached code will help generate good design ideas. Andrei
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
