Nullable input/output with type converters

[tenhobi]

Nullable input/output with type converters

[ekerik220]

I need this functionality so I took a look at the code and I think I see how this could be implemented. I want to clarify the requirements though, if possible.

In cases when Object is expected (source or target) and a type converter is set with Object?, this converter should handle it.

Does this mean if we had a TypeConverter<Object?, Object?> it can be used for all conversions?

• Object -> Object
• Object -> Object?
• Object? -> Object
• Object? -> Object?

I think anything with -> Object could be a problem for this type converter, since the function that will handle the conversion could possibly return null. I think it's reasonable for it handle both Object -> and Object? -> though, since the conversion function would be built to handle a nullable input, which can also be used to handle a non-nullable input just fine.

In cases when Object? is expected (source or target) and a type converter is set with Object, this converter should not be used.

So in this case, if we had a type converter TypeConverter<Object, Object>, it would not be usable to any conversions that have a nullable source or target? I think it could technically handle -> Object? conversions as well, since the non-null value returned by the conversion function could still be assigned to a nullable variable, but I'm not sure if it should handle it or not.

So I think maybe there is a design choice to be made. TypeConverters with nullable generics can technically handle some non-nullable cases safely, and TypeConverters with non-nullable generics can technically handle some nullable cases safely, but I guess the decision is whether they should or not. We could make them really strict so that the type and the nullability of the type has to match exactly, and that might be easier to understand for someone using the API, but it would also mean that their code might have to be more verbose to cover all the scenarios they need.

What do you think?

[ekerik220]

Thanks for your quick reviews and release! I'm using the feature now. 🎉

[tenhobi]

Hi @ekerik220 thanks for your initiative! Hmm, you are probably right. Thinking about it more, should it work like this?:

Aka choosing the solution that works the same way as if you had some converter function and manually using it in code. And in the end, that's exactly what type converter is doing under the hood - you assign such a function to it.

• TypeConverter<Object, Object> ... aka Object converter(Object) => ...
  • Object -> Object
  • Object -> Object?
• TypeConverter<Object, Object?> ... aka Object? converter(Object) => ...
  • Object -> Object?
• TypeConverter<Object?, Object> ... aka Object converter(Object?) => ...
  • Object -> Object
  • Object? -> Object
  • Object -> Object?
  • Object? -> Object?
• TypeConverter<Object?, Object?> ... aka Object? converter(Object?) => ...
  • Object -> Object?
  • Object? -> Object?

So the most universal type converter that can handle every case will be TypeConverter<Object?, Object> probably?

This enhancement should be well-tested for sure.

[tenhobi]

The test should be similar to the lists I posted above, aka 4 groups with 9 tests total. That should test every case.

[ekerik220]

That looks good to me! For sure, this enhancement has a lot of possible cases so all of the cases should be tested.

Do you have any suggestions on how this should be tested? I think generating and using a mapper like in the current integration tests gets us part of the way there, and maybe unit testing TypeConverter.canBeUsed would be good too.

I made a quick implementation that I think might work. No tests yet, but let me know if you think it should be done differently or if I'm missing something. #130

[tenhobi]

So released in auto_mappr 2.1.1 and auto_mappr_annotation 2.1.0 🎉