What about to add the capability to set properties with given set of values?

[lorenzomar]

Hello, i would like to use this package in a project where i serialize/deserialize entities in/from json file. I know that when applied to the full ORM it is up to the hydratator to populate the instantiated object with the right values respecting the mapping etc, but when used alone i feel that the package is missing the capability to populate the instantiated object with given values. What do you think about?

[Majkl578]

You should use separate library for (de)serialization, e.g. jms/serializer.

[stof]

This is indeed out of the scope of the library. This package is only about instantiating an object without going through the constructor.

[Ocramius]

This was actually in the initial scope as per Ocramius/Instantiator#1 and Ocramius/Instantiator#11.
Being able to retrieve a factory that expects a PRECISE key/value array for properties to set would be very useful as an exact counterpart to the (array) $object cast (basically $instantiator->toObject($array, $className).

The work has been stopped because of:

• lack of time
• reduced performance throughput (if we do this, it better be fast as heck in order to be usable in D2 internals as well)

[Ocramius]

/cc @malukenho

[lorenzomar]

I agree with @Ocramius. I don't think it is out of scope. My knwoledge of Doctrine internals isn't good enough to give any opinion about the integration with the ORM but, limiting the scope to this package, i look at this capability as a natural evolution. Maybe the purest way is to have an instantiator and a "setter" or "populator" or any other name that makes sense, but i can't imagine a situation where the two are used separately. If the need is to instantiate an object without setting properties, can be passed an empty data set.

[Ocramius]

Maybe the purest way is to have an instantiator and a "setter" or "populator" or any other name that makes sense,

That's a separate thing, tbh (hydrator)

[stof]

That's a separate thing, tbh (hydrator)

and this is exactly why I think it should live in a separate library, not here

[lorenzomar]

I don't think it is a concern of hydratator. Correct me if i'm getting wrong, but the hydratator job is to get raw data from any source, reading mapping, collect custom types (if any) and build a pool of objects (proxy, custom types, other entities, ecc) that are used to build the final class (entity from the point of view of ORM). The current package is about the building process of the final class, not the intermediate processes related to ORM.
Am i getting wrong?

[Ocramius]

That's a separate thing, tbh (hydrator)
and this is exactly why I think it should live in a separate library, not here

True, I'd just like to simplify it down to a "one shot constructor replacement", so it's not really what the hydrator does.

I built https://github.com/Ocramius/GeneratedHydrator to experiment with the performance implications, but we'd still need to go one step further to make it also instantiate things for us (and consider all the php-src issues we had here).