Prepare for hydration of typed properties as supported by PHP 7.4 about yang HOT 8 CLOSED

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.

from yang.

Yep, I like it :) Thanks!

from yang.

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

from yang.

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 😄

from yang.

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

from yang.

@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()

from yang.

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

from yang.

Sure! I'll release it this week :)

from yang.