commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Legostaev, Andrei" <>
Subject RE: [convert] Additional code
Date Tue, 23 Mar 2004 02:37:06 GMT

My apologies for the previous message that got stripped of its
attachment and chopped to pieces by the ill-tempered mailing 
list robot.

Please find the source compressed in Windows and UNIX flavours
here (with thanks to Mr Reeve):

> 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:
For additional commands, e-mail:

View raw message