I like all those suggestions a lot. Your use cases are very convincing
(probably b/c they're from a real live app!)
What do you think of the ConversionFactory.getMatchPercent method? This
seems inappropriate for an interface to me. This seems like it belongs in
an implementation of ConversionFactory and that the ConversionFactory
interface should be simplified. I think this relates to point #2 of yours
below...
Matt
----- Original Message -----
From: "Legostaev, Andrei" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 22, 2004 1:55 PM
Subject: [convert] Use cases not currently covered
>
> Greetings All
>
> I have been corresponding with Stephen regarding some design decisions
> being made in [convert]. I'd like to make a couple of pugnacious
> declarations and hope that ensuing discussion generates good ideas and
> consensus.
>
>
> I'll first state my beliefs, then I'll try to justify them belief at
> great length :-)
>
>
> 1) The actual conversion logic should be implemented in small chunks,
> inside the most primitive, bare code-container, interface :
>
> public interface Conversion {
> public Object convert(Object value) throws Exception;
> }
>
> One implementation should do one simple, well-specified conversion,
> e.g. String to Integer. The implementation should be free to make
> documented assumptions about its input and free to throw any exception
> if an assumed precondition is broken.
>
>
> 2) There should be multiple manager classes to implementing distinct
> policies for choosing a Conversion. ConversionRegistry will be one
> such manager. Other managers may build transitive Conversion chains,
> handle inheritance, provide accessors for primitives, etc. Clients
> will work with managers, never Conversions themselves. Managers will
> wrap exceptions thrown by Conversions in ConversionExceptions. There
> is no one interface that could sum up all possible managers.
>
>
> I recently implemented a framework similar to [convert], also inspired
> by the limitations of BeanUtils. The framework evolved to support a
> large (1.5m lines) family of business applications. The result of the
> painful evolution was what I described above.
>
>
> For example, having the concepts of "from type" and "to type" near the
> core of the framework proved unhelpful.
>
>
> One use case where this broke down was this :
>
> Legacy business objects often use java.util.Date to represent any or all
> of a) bare date b) bare time c) date-time. Therefore in flattening the
> properties of such objects to text three different rules are applied for
> the java.util.Date -> java.lang.String conversion.
>
> By eliminating the "from type"/"to type" concept from the core, this use
> case can be handled cleanly. It requires a simple manager semantic that
> associates a Conversion with a Method or property name.
>
>
> Another use case forced the simplification of the Conversion interface :
>
> There are cases where a Conversion is highly customized or involves
> non-public types. Being able to implement it as an anonymous class
> is very important.
>
> registry.register(GUID.class, new Converter() {
> protected Object convert(Object value) {
> String string = value.toString();
> return new GUID(string.startsWith("0x") ? string.substring(2) :
string);
> }
> });
>
> This code snippet deals with a quirk of a minor legacy API that may or may
> not add a "0x" prefix to hexadecimal values. If it were hard to implement
> the rule in-line, clients would've opted to hack around the conversion
> framework, sharply reducing its value.
>
>
> I am currently negotiating with my employer to release the code to
Jakarta.
> Hopefully it will help generate some more ideas.
>
> Andrei
>
> ---------------------------------------------------------------------
> 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]
