Optional hydration

[flip111]

Allows for properties to be skipped when not found in data array.

Some considerations:

1. line length too long
2. double declaration of var_export($accessibleProperty->getName(), true)
3. not configurable
4. isset() might not be optimal here, possibly use ternary operator
5. ... ?

[Ocramius]

This requires a different generated class. The checks should not land in runtime.

[flip111]

That would mean the factory has to rerun to create the right object for the type of data passed in??

[coveralls]

Coverage decreased (-1.15%) when pulling c8fad87 on flip111:patch-1 into fd458d3 on Ocramius:master.

[Ocramius]

Right: no decision making at runtime

[Ocramius]

If we can schedule this for 2.0 (which is fine) you can add the array hint here

[Ocramius]

Also fix the docblock

[Ocramius]

The approach seems to be much better now :)

[flip111]

instead of un-setting them, create a new private method that filters them via array_filter

key is not available to the callback used by array_filter

[Ocramius]

@flip111 yep, but keys are preserved ;-)

[flip111]

Yes but the filtering per element depends on the key of that element

[Ocramius]

@flip111 you are not really using the key except for the unset() call

[lisachenko]

@Ocramius @flip111 it's also possible to use array_intersect_assoc )

[Ocramius]

Lol, so we will have to lookup the php manual every time we need to know
what that code does :p
On 23 Apr 2014 07:55, "Alexander Lisachenko" notifications@github.com
wrote:

@Ocramius https://github.com/Ocramius @flip111https://github.com/flip111it's also possible to use
array_intersect_assoc )

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/16#issuecomment-41127155
.

[flip111]

@lisachenko array_intersect_assoc doesn't work here. I have one array with Key => Value and another array with only value (keys auto numeric). Now i need to remove elements from array 1 where key is in values of array 2. array_intersect_assoc works when array1 and array2 have the same structure (key on key and value on value), i have key on value.

Anyway @Ocramius i did all the changes except for this one. Not sure what is the optimal approach here o_O.

[Ocramius]

@flip111 segregate all the things in private methods :D

[Ocramius]

@flip111 a rebase as well as test cases for this are required...

[flip111]

Noted! Though might take some time over here ...

[flip111]

I got a bit confused because the dev-master got updated. I can not see the changes in comparison to the current dev-master (or don't know how). Perhaps instead of a rebase i can just open up another PR so the diff becomes more clear as well.

[Ocramius]

@flip111 the PR still looks fine to me. I can rebase it myself if needed.

[flip111]

I was waiting for your toolchain to run (i.e. travis), but that didn't happen yet?
If you think the PR looks fine, please go ahead rebase and merge :)

[stof]

@flip111 Travis does not run PRs which are not mergeable. This is why it does not run. It would run after a rebase

[flip111]

@Ocramius is this PR still looking fine to you? Is the only blocker that rebase? Did the state of the library changed so much that this PR is unmergeble in it's current state? I would like to push this to finish in the upcomming time. Would be great if you can give your pointers, blessing and that mouse click on the holy merge button.

[stof]

@flip111 it was already conflicting with master in May. This has not magically resolved

[flip111]

I think there is a good use case for not having hydrate and extract work on the same properties. Maybe you want to just hydrate an id of an object when coming from a database, but you want to extract all the properties for sending the data off to another destination.

I wrote a library before where i could choose between extract and hydrate. But i want to go further than that. One thing that would be nice is to also make some data optional. So instead of having

$this->barWriter5640e58591b7c415996372->__invoke($object, $data['bar']);

You will get

if (isset($data['bar'])) {
  $this->barWriter5640e58591b7c415996372->__invoke($object, $data['bar']);
}

Configuration could be done by a data structure (arrays). For example:

["foo", "bar"]

Or if you need more finetuning per property:

[
  "foo" => [
    "extract": true,
    "hydrate": "optional"
  ]
  "bar" => ]
    "extract": "optional",
    "hydrate": false
  ]
]

---

This implementation could possibly be replaced by custom visitors as in #40

The custom visitor class would have to be added to this library though, otherwise other users of this library do not get this functionality.

One huge disadvantage in my opinion is that adding a bunch of visitors in a certain order will cause that they are not compatible with each other anymore ...

At least this way you have the guarantee that all the options works together. And also coding is much easier then to mess around with the AST all the time.

---

@Ocramius i'm gonna go ahead and start working on another version of this PR with the above mentioned options (but not by doing it with visitors). I'm leaving this PR as it is for now. Hopefully you will have some time to review this.

I do have one more question though ... is it possible to generate more hydrator classes (cached for production) for the same class? In case you want different versions that serve different options...

[flip111]

New version is ready

[pounard]

For what it worth, PR #59 should fix this issue by mostly removing code, not adding some.