Looks like your link got somehow broken, here it is once again:

On the core subject: I personally think that PropertyAccess is somehow used for the wrong case here. It does fit at this moment, but not for your use case, unfortunately. Basically, what we want here is a hydrator instead, and such a hydrator should be able to deal not with withers, but basically with anything. Withers are just the style of immutability you've chosen to use; what if my models don't have these at all? I could be just using the constructor to pass the values into my instances, relying on other code to somehow clone the initial model. This style would require PropertyAccess to be able to access properties that are actually private and non-settable at all. (Also, how would you guess the argument order for the constructor here?)

Something like GeneratedHydrator would fit here, but what the ObjectNormalizer would then need here is a strategy to pick the best and most performant of the available hydration methods.

Looks like your link got somehow broken [...]

Fixed

On the core subject: I personally think that PropertyAccess is somehow used for the wrong case here. [...] Basically, what we want here is a hydrator instead, and such a hydrator should be able to deal not with withers, but basically with anything. [...] what if my models don't have these at all? I could be just using the constructor to pass the values into my instances [...]

I couple of thoughts on the fly: There is two problems at hand: instantiating the object and populating it. And in this part (setAttributeValue) we are talking of populating it (which is what an hydrator is about correct?). If you have no "mutator" (I'm putting quotes as I'm including withers or any equivalent here) but are putting everything in the constructor, there this case has already been taken care of at that point.

This style would require PropertyAccess to be able to access properties that are actually private and non-settable at all.

I'm not a big fan to "hack" things to set private values. Not that it's not a valid use-case but it can create some unexpected issues as you are setting your model state in a non conventional way. It's a scenario where I would rather see developers use custom serializers or if they are fine with this behaviour, enrich the serializer behaviour in their code base (i.e. not providing that in the core).

I personally think that PropertyAccess is somehow used for the wrong case here

I may have got the wrong idea on what the PropertyAccess is about and someone more knowledgeable may correct me, but to me it looks like PropertyAccess simply has two facets:

• Reading a value from an element (array/object) (in which case it is an accessor)
• Writing a value to an element (array/object) (in which case it is an hydrator)

For both, part of that process is figuring how to access/write the value which includes checking if the property is public or not, if there's a getter, is using camelcase or snake case and so on.

Withers are just the style of immutability you've chosen to use

100% agree with that. It is a convention like another which looks like widly adopted (I have no data to back it up, it is only from my personal experience) and I believe that if there is another popular convention, it should be supported as well (provided it's worth it).

So for those reasons I don't feel like it's misusing the PropertyAccess component :)

@theofidry, on second thought, the PropertyAccess is not actually the case for immutable models, since it's a constructor and not an accessor anymore for those. We never get to modify the exact model, we get a new one every time. It's just the naming, but the naming and its interface suggests that it should be accessing properties of a single object, whereas withSmth would return a new object each time. So it looks like some other component should be involved here :)

@kix I would say it still is. You are write, "wither" and so are actually non-static factories. However because they are non-static, they require an instantiated factory which is the instance itself.

To me this would still fall within the responsibility of an hydrator: you have an object and properties to populate, and you and a populated object. That the populated object is the same or not than the input one is nothing but a detail.

As said I wouldn't mind having it as a separate component or outside of Symfony, but the issue is that it relies on private methods of PropertyAccessor, because the lookup strategy to find the method is the same: https://github.com/symfony/property-access/blob/master/PropertyAccessor.php#L709

As discussed in off, there is not need for that as it can be solved by ensuring the object is properly populated when instantiating it. The only edge case that would not work would be if a property should be set with a withX but can't be set with a constructor/factory, in which case a "fix" is easy.