Repository navigation
Generalize ConvertService + Converter #109
Description
Activity
We should also split the
DefaultConverterinto severalConverterimplementations with proper prioritization, to eliminate the monolithic case logic of the current code.Also,
ClassUtils#setValueusesConversionUtils. This has the potential for problems within multi-context environments. Essentially this means thatClassUtils- or at least parts of it - should be contextual.We should also have a
NullConverterthat runs first to catchnullinputs, and remove the logic to acceptnullsfrom theAbstractConverterlayer.@dietzc raised a good question - why does convert take an
Objectand not anIparameter.Right now the answer, I believe, is to allow accepting collections and primitive arrays of type
Ias input as well. But maybe we should just always be unwrapping these multi-element inputs and relying on converting the individual elements..?why does convert take an Object and not an I parameter.
Convenience at compile time. It is the same reason that
Collection#containstakes anObjectinstead of anE. I don't think there is any harm in allowing a non-Iparameter to be specified.maybe we should just always be unwrapping these multi-element inputs and relying on converting the individual elements
The idea was to create a separate
Converterfor collections, which recursively leans on theConvertServiceframework for individual elements. This will reduce the SLOC count while also making conversions more robust and easier to understand.As part of this work, we should also reconsider the
canConvert(Type, Type)style signatures. Right now, they are deprecated, but stuff still uses them. And I think we still need them! At least, the OPS matcher does. So they should really not be deprecated...- added a commit that references this issue
on Dec 9, 2015
The ancestors of these classes evolved to have API for handling
TypeandClassseparately. This is unnecessary.. we should unify this API by focusing onTypeand special-casingClass.This will simplify things and reduce the number of signatures.
Furthermore the API of
<T> convert(Object, Class<T>)is really a holdover from the old uber-conversion mindset. What we should have is:NullConverter)castingConverterthat handles casting. This implies that low-level converters do not cast, but provide their specific output type.O convert(I)