-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: use T -> R
type converters for T? -> R?
convert
#142
Conversation
1a11ea0
to
d0f63ea
Compare
T -> R
type converters for T? -> R?
convert
Hello again! I will check this on Monday in more detail. The logic and basically mitigation of how input parameter and return value works in functions is discussed here #128 (comment) But I will take a look at this case. Could you maybe provide more detail with why etc? 😊 |
Sure, after reading #128 (comment) I don't think that it's currently possible to write a single Short example: class ExampleId extends ValueId<int, ExampleId> {
const ExampleId(super.value);
}
@AutoMappr(
[],
converters: [
TypeConverter<int, ExampleId>(ExampleId.new),
],
)
class ExampleMappr extends $ExampleMappr{
const ExampleMappr();
} Sidenote the overview given in #128 (comment) might help some people if it was in the readme. |
First of all, we can add that list to readme, good point! I see now, " I extended the support for this also for Aka the proposed change is
|
I am also thinking, should there be an option to disable/enable this, or should we keep it always on? |
I do think that the change should always be enabled by default but I am not sure if this is a breaking change. Might be best to release as a new major version. I do not see why one would want to turn this feature off so a feature flag / build configuration value thingy isn't required unless someone asks for it in the future I guess. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the great work @DevNico
This will allow usage of
T -> R
mappers where a mapping ofT? -> R?
is required. This could technically be a breaking change if someone expected to have null be set instead of the mapped value.