commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Legostaev, Andrei" <Andrei.Legost...@gs.com>
Subject [convert] Additional code
Date Tue, 23 Mar 2004 00:06:00 GMT

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



Mime
View raw message