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 classes.
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 times.)
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.
Oliver
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 RB> http://www.rblasch.org/convert/convert-docs.zip
A snapshot of my prototype is also available at http://www.rblasch.org/convert/convert-proto2.zip
The code is A Real Mess and may cause brain damage. You have been warned.
Ron
--------------------------------------------------------------------- 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]
