Add support for Stringable as DataSubjectId

[wikando-ck]

Adds a failing test to demonstrate desired behaviour.
Adds the necessary feature to the PersonalDataPayloadCryptographer.

Let me know if this should rather target 2.x or needs to be ported there.

[wikando-ck]

I'd usually return early here, but followed the style from above with the casted int.

[DanielBadura]

Based on my other comment, maybe the cast from int here is also wrong at this place. This should be handled in the normalizing layer and not here. wdyt @DavidBadura ?

[DavidBadura]

@DanielBadura Nothing is normalized here. The data is already normalized when it enters this function. SubjectId must be a string, that's why the cast is done. And integer remains an integer when normlicized.

[DanielBadura]

What is the exact issue you have? Do you have a 3rd party object which is implementing this Interface or do you have an own value object?

[DanielBadura]

We would also need a decrypt test case. This would also uncover a problem with this approach as I think: The Stringable is a one way ticket. It does not define a way back, this means we cant transform the decrypted scalar value back to the object it was before. Thats also the reason why we dont ship a StringableNormalizer with the library.

I think transforming the object to a scalar string should be done via normalizer so that the cryptographer can ignore the transforming part and just handle the de-/encryption.

[DanielBadura]

Based on my other comment, maybe the cast from int here is also wrong at this place. This should be handled in the normalizing layer and not here. wdyt @DavidBadura ?

[DavidBadura]

So, PersonalDataPayloadCryptographer works on normalized data. In other words, an object should already be converted to a scalar value. If this isn't the case, it means that a normalizer for the object is missing, which is why it's still an object here. Sure, we can cast it to a string using Stringable, but your original problem still exists and the extraction still doesn't work properly. In other words, you're just postponing the error. But...

@DanielBadura , I think the change still makes sense, because from the perspective of PersonalDataPayloadCryptographer, subjectId doesn't need to be converted back to an object, so it doesn't care whether the normalization worked or not. Its scope works. Instead of the normalizer, the user can also convert the data into a string using the event system after Cryptographer, e.g. a custom upcaster etc.

[wikando-ck]

In other words, you're just postponing the error.
I think this is what I did :)
I was trying to work around with the idea of not wanting an identifier in my value objects and got mixed up in multiple approaches. In the end I still need to add it and can just use the IdNormalizer in this case.

Feel free to close, if you decide the edge case of denormalizing the subjectId in a different way is not worth adding.

[DanielBadura]

@wikando-ck we decided to merge this and release this soon. Thanks for the contribution! 🚀