Skip to content
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

Metadata for hydrator generation? #38

Open
sandermarechal opened this issue Sep 14, 2015 · 2 comments
Open

Metadata for hydrator generation? #38

sandermarechal opened this issue Sep 14, 2015 · 2 comments

Comments

@sandermarechal
Copy link

@Ocramius and others, I wonder what your opinion is about metadata for hydrator generation.

For example, I'd like to see integration for hydrator strategies or nesting hydrators, but it seems to me that you'd need to have some kind of metadata about how to map the array to the object. Thinks like, for example:

  • DateTime hydration. What format is the date in?
  • Nesting hydrators. Have ['bar' => ['quu' => 'quuz']] arary, hydrate to a Foo object that has a Bar object as property. The FooHydrator would need to call (or inline) the BarHydrator.
  • Array hydration. How to hydrate or extract an array of objects.

I think some kind of metadata is required to support these use cases, but I don't think you'd want to replicate a large part of e.g. JMS/Serializer. The point of generated hydrators is to be very, very fast.

What would be a sane way to go about this?

@Ocramius
Copy link
Owner

I wonder what your opinion is about metadata for hydrator generation.

More like a DSL for how to define a hydrator (that would really be useful).

What you are asking for is a bit far fetched, tbh, but it can be done.

I have no plan on how to approach it, but the idea is to have:

  • some DSL for hydration (kinda like an AST)
  • AST walkers to simplify the AST and reduce complexity (for example, grouping operations on the same scope)
  • (eventually, optional) an AST builder, although I would leave this until the very last moment
  • an AST to code generator

@pounard
Copy link
Contributor

pounard commented Nov 29, 2017

By creating a simpler and specific AST for hydrators only, this would allow to get rid of the nikic/parser dependency, and remove a lot of complexity from the existing code, at the cost of having to maintain its own AST - but I think that, if the goal of this API is to generate complex hydrator trees for specific needs, it would worth it. It would also allow to do things such as a bridge to Symfony property info component (that would work both ways actually).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants