Prepare for hydration of typed properties as supported by PHP 7.4

[holtkamp]

As of PHP 7.4, typed properties are supported. In case typed properties are used for "mapped" classes used during resource hydration as discussed in #20, the property types of the used class should be respected.

For example:

• a property of type float can not be assigned a returned string value of 1.0
  • By detecting the type of the property, the value can be determined as (float) $value
• a property of type DateTimeImmutable can not be assigned a returned string value of '2020-01-01T10:59:59.711148+02:00
  • By detecting the type, the value can be determined as new DateTimeImmutable($value)

Therefore, next to the DocumentHydratorInterface, a DocumentPropertyHydrator or DocumentAttributeHydrator interface would be nice to have to use prepare for this functionality to be used here. Note this requires PHP 7.4or higher.

Already have a working approach, just created this issue to get it out of my head and be able to discuss it before spending time on a PR and tests 😉

@kocsismate What do you think?

[kocsismate]

Hi @holtkamp ,

Interesting idea! However, it seems to be a bit fragile for me :( What happens with interfaces? For example when the property is a DateTimeInterface? Or when the instantiation of the object is not trivial, e.g. when it contains more constructor parameters? We can't even be sure that the constructor is available because it might not be public.

That's why I prefer hydrating Data Transfer Objects - which are simple data bags. I usually map them to Value Objects if some kind of validation is needed, or directly use them for presentation.

If your preferred workflow is different then the best thing in my opinion to do is override the ClassDocumentHydrator::hydrateResourceAttributes() method - but I think this is what you did anyway. :) It might make sense to create a custom hydrator for each resource if the mapping is not trivial.

To be honest I was always sceptical about general solutions for mapping/hydration which are too advanced because they tend to be fragile (in the sense that people will always keep finding features that it doesn't have yet), and I think it's much easier and less complex to do the mapping/hydration manually - for the price of some repetitive work.

[holtkamp]

Nice observations!

If your preferred workflow is different then the best thing in my opinion to do is override the ClassDocumentHydrator::hydrateResourceAttributes() method - but I think this is what you did anyway. :)

Indeed, and while doing this, I thought: this can be isolated more by using interfaces: so my "only suggestion" was actually this:

Therefore, next to the DocumentHydratorInterface, a DocumentPropertyHydrator or DocumentAttributeHydrator interface would be nice to have

The example with typed properties I gave was an illustration of "why" this would/could be useful.

So "by default" nothing will change, but one can choose to implement a custom DocumentHydrator, which uses a custom DocumentPropertyHydrator/DocumentAttributeHydrator

Code would probably explain the suggestion better, I can try to come up with a PR and then we can discuss the added value there 😄

[kocsismate]

OK! I'm looking forward for the PR :)

[holtkamp]

@kocsismate as you can see the change is small, but opens up the possibility for somebody to write his own AttributeHydrator without the need to use inheritance to specialize ClassDocumentHydrator::hydrateResourceAttributes()

[kocsismate]

Yep, I like it :) Thanks!

[holtkamp]

Thanks for merging, does this justify a new minor release? Then this issue can be closed.

[kocsismate]

Sure! I'll release it this week :)

[kocsismate]

@holtkamp Release is done :) https://github.com/woohoolabs/yang/releases/tag/2.3.0