commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [convert] Additional code
Date Tue, 23 Mar 2004 00:21:17 GMT
You may need to attach code to a Bugzilla request (select Commons then
Sandbox, prefix by [convert]). Or make available by a link.
Stephen

----- Original Message -----
From: "Legostaev, Andrei" <Andrei.Legostaev@gs.com>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message