commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Oliver Heger)
Subject Re: [convert] Initial ideas (was: conversion with default values)
Date Sat, 27 Mar 2004 16:22:00 GMT
I had a look at your ideas and now I have a few questions and remarks.

At first let me say that I like the idea of using a graph representation 
and a kind of shortest path algorithm to determine a conversion chain 
very much. I think this is something we will need to make [convert] 
really flexible. With the percentage values used at the moment on the 
other hand I belief it is very difficult to define an appropriate 
priority order, especially if those values are hard coded in the factory 

The idea to use a separate lookup class seems interesting, too. But 
after thinking a while about it I am not sure if this really helps 
because of the following points:

1. A lookup class will probably need some meta information to find the 
group of converters to use for the actual query. This meta information 
can be different for different implementations, e.g. weights for the 
graph's edges. The place to store this information is certainly the 
registry. So this would imply that for different lookup classes other 
data has to be stored in the registry. Can this be handled in a generic 
way or wouldn't it be better to leave the lookup mechanism in the 
registry and use different registry implementations?

2. A lookup might be expensive, especially if a search in a complex 
graph has to be performed. So it might make sense to implement some 
caching functionality. I am not sure if this can be done efficiently in 
a lookup class implementation because in your example code always a new 
lookup instance is created (though I might miss something here).

No my further questions:

The approach with the Types handles inheritence, but does it cover all 
cases? I am not sure if the following use case could be handled: imagine 
a user has the classes A, B, C, and D with B and C extending A. Then 
there are special conversion implementations for A->D and B->D. If now 
an object of class C is provided, will then the A->D conversion be used? 
With other words: inheritence in direction towards the base classes is 
surely supported, but can derived classes be handled without extra means?

What about structural conversions, e.g. a String[] to a int[] or a 
collection of Integers to a byte[]? Where would these conversions take 
place? (I think this is slightly different from constructing a chain of 
conversions because here a base conversion has to be performed multiple 

One last remark about the extended converter interface: I think I 
understand why this ConversionContext is needed - to allow a single 
object being treated as of different types. But I strongly agree with a 
statement mentioned on this thread: that the converter interface should 
be as simple as possible. So if it is possible, I would try to get rid 
off this additional complexity.


Ron Blaschke wrote:

>SC>>> Basically the sooner you can make available
>SC>>> ideas/designs/code the more it
>SC>>> can be talked about ;-)
>RB>> Point taken.  Please find attached a summary of my thoughts (well, not
>RB>> all of them; just those related to convert).
>RB> Don't know if the images made it to the list, so you'd better get
>A snapshot of my prototype is also available at
>The code is A Real Mess and may cause brain damage.  You have been
>To unsubscribe, e-mail:
>For additional commands, e-mail:

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

View raw message