-
-
Notifications
You must be signed in to change notification settings - Fork 141
[Platform] Improvements on Uuid handling & MessageNormalizer
#1001
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
base: main
Are you sure you want to change the base?
Conversation
MessageNormalizer
MessageNormalizerMessageNormalizer
f4e9f4b to
5896900
Compare
e8cc913 to
604d5aa
Compare
chr-hertel
left a comment
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.
My assumption as user would be that a withId clones the instance - and that would also help here, right?
we could keep the instantiation of id in the constructor but overwrite if needed with that withId
|
Make sense, I was focused on the method and not its usages, to be honest, I was looking at the method last night and said to myself: Damn, that's ugly as hell in the constructor 😅 |
604d5aa to
6fa847e
Compare
6fa847e to
27f59fd
Compare
27f59fd to
ae9096d
Compare
well, we've all been there - over and over ... |
ae9096d to
61432a0
Compare
61432a0 to
bbe4588
Compare
Summary:
MessageNormalizer::denormalize(), it looks like we're recreating a newUuid::v7()in the constructorIdentifierAwareTraitthat expose two methodsgetId()andwithId, the last one allows to either specify an exiting Uuid or use av7one