You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are cases where " air " == " AIR " but with current code, the caller has to ensure that Value.From(...) is always called with .ToUpperInvariant(), .Trim(), ... or similar to ensure equality and proper ToString representation
Either a Flag, an Attribute or even "magically" understood method to provide the "normalized" Value would be great. Latter would allow us to do whatever we want with the value object on creation.
the generated code would then look somewhat like this
publicstatic Value From(stringvalue){value= Value.Normalize(value);Valueinstance=new Value(value);varvalidation= Value.Validate(value);if(validation!= Vogen.Validation.Ok){thrownew Vogen.ValueObjectValidationException(validation.ErrorMessage);}returninstance;}
It would also allow for clamping of numeric values for example, where a "larger" value isn't technically a cause for an exception but allowed to be silently "fixed"
The text was updated successfully, but these errors were encountered:
kirides
changed the title
Add ToUpperInvariant/ToLowerInvariant for ValueObjects from string
Add support for "normalizing" ValueObjects from stringFeb 11, 2022
kirides
changed the title
Add support for "normalizing" ValueObjects from string
Add support for "normalizing" ValueObjects
Feb 11, 2022
Good idea! I had a similar concept in a previous implementation of this library; it was a delegate passed that did translation (and as I recall, it was exactly for this kind of this - to sanitize data)
Describe the feature
There are cases where
" air " == " AIR "
but with current code, the caller has to ensure thatValue.From(...)
is always called with.ToUpperInvariant(), .Trim(), ...
or similar to ensure equality and properToString
representationEither a Flag, an Attribute or even "magically" understood method to provide the "normalized" Value would be great. Latter would allow us to do whatever we want with the value object on creation.
the generated code would then look somewhat like this
It would also allow for clamping of numeric values for example, where a "larger" value isn't technically a cause for an exception but allowed to be silently "fixed"
The text was updated successfully, but these errors were encountered: