You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Legostaev, Andrei" <An...@gs.com> on 2004/03/22 19:55:59 UTC
[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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [convert] Use cases not currently covered
Posted by Ron Blaschke <ma...@rblasch.org>.
LA> 1) The actual conversion logic should be implemented in small chunks,
LA> inside the most primitive, bare code-container, interface :
LA> public interface Conversion {
LA> public Object convert(Object value) throws Exception;
LA> }
I agree that the interface should be small, but I am not too sure
about the Exception. Throw-everything forces the caller to
Catch-everything. Maybe a more specific Exception, like
ConversionFailedException, is sufficient.
LA> One implementation should do one simple, well-specified conversion,
[...]
Agreed.
LA> 2) There should be multiple manager classes to implementing distinct
LA> policies for choosing a Conversion. ConversionRegistry will be one
LA> such manager. Other managers may build transitive Conversion chains,
LA> handle inheritance, provide accessors for primitives, etc. Clients
LA> will work with managers, never Conversions themselves. Managers will
LA> wrap exceptions thrown by Conversions in ConversionExceptions. There
LA> is no one interface that could sum up all possible managers.
I also agree very much, but I'd like to see an intermediate structure
to store converters (which I have presented recently as
ConverterRegistry). The managers (ConverterLookup, or however it may
be named) would provide the algorithm to work on the converters.
[snip]
I like the ideas you presented quite a bit. The one thing I don't
understand is how you decide which converter to take. In other words,
why don't you need the input/output type information?
If you want, check out my ideas at
http://www.rblasch.org/convert/convert-docs.zip
http://www.rblasch.org/convert/convert-proto2.zip
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [convert] Use cases not currently covered
Posted by Matthew Sgarlata <sg...@crystalcognition.com>.
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" <An...@gs.com>
To: <co...@jakarta.apache.org>
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: 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