commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Blaschke <>
Subject Re: [convert] Use cases not currently covered
Date Mon, 22 Mar 2004 23:24:37 GMT
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,


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.


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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message