--- On Sat, 2/13/10, Adam Heath <[email protected]> wrote: > From: Adam Heath <[email protected]> > Subject: Re: Conversion framework is not 'most specific' compatible > To: [email protected] > Date: Saturday, February 13, 2010, 4:58 PM > Adrian Crum wrote: > > --- On Sat, 2/13/10, Adam Heath <[email protected]> > wrote: > >> From: Adam Heath <[email protected]> > >> Subject: Conversion framework is not 'most > specific' compatible > >> To: [email protected] > >> Date: Saturday, February 13, 2010, 1:09 PM > >> When Converters.getConverter doesn't > >> find an exact match for a > >> conversion request, it loops over all registered > converts, > >> and asks > >> then if they can handle it. However, this > looping is > >> not in any > >> particular order, as it is based on Map.values(), > which is > >> mostly random. > >> > >> This means if there was a Converter registered for > Map, and > >> another > >> registered for LinkedHashMap, that if code tried > to > >> convert > >> org.ofbiz.base.util.collection.LRUMap, it's > unknown which > >> Converter > >> would be returned. I would say LinkedHashMap > is more > >> correct. > >> > >> Then, if there was a Map and MyNewInterface > Converter > >> register, and a > >> conversion request comes in that implements both > those > >> interfaces, > >> then which one should be returned? > >> > >> Java compilers(janino is one I am semi-familiar > with it's > >> internals), > >> are designed to handle this. But the > algorithm isn't > >> the simplest. > >> > >> I suggest that if multiple Converters are found > for a > >> request, that an > >> exception gets thrown, and a warning logged. > > > > Why not add code that finds the closest match (or most > specific) in the case of more than one match? > > Because such code is complex. Let's say there are > converters for Map, > FooInterface, BarInterface, BazInterface, > BarAndBazInterface, and > AbstractMapAndFooInterface. Then, and object that > extends > AbstractMapAndFooInterface, and implements both > BarInterface and > BazInterface. Picking the correct converter is a > little difficult in > this case.
Good point, but couldn't we at least try to come up with a set of rules or a strategy instead of throwing an exception? It seems to me that throwing an exception is an easy way out for the designer, and a big pain in the butt for the user.
