Add `getFieldValue($object)` and `setFieldValue($object, $value)` to `ClassMetadata`

[GromNaN]

Feature Request

What

Since doctrine/orm#11659, the way to access the value of a field has changed. This change required a patch in Symfony symfony/symfony#59887 that then have to be patched again for ODM symfony/symfony#60953

In order to establish a safe way to get and set the property values of an object through its class metadata, the methods getFieldValue($object) and setFieldValue($object, $value) need to be defined in the interface.

This method already exist in implementations:

• ORM: https://github.com/doctrine/orm/blob/ee919d62315680a607331d1cf0852c874362b522/src/Mapping/ClassMetadata.php#L686
• ODM: https://github.com/doctrine/mongodb-odm/blob/6f4f0fbc51e918144839de0ca5377ed5dcec3b3f/lib/Doctrine/ODM/MongoDB/Mapping/ClassMetadata.php#L1913

Why

Accessing a field value need to be in a common interface, that all Doctrine ORM/ODM projects can implement.

How

Adding a method to an interface is a breaking change; in order to introduce this new method, a new interface can be introduced.

[greg0ire]

Adding a method to an interface is a breaking change; in order to introduce this new method, a new interface can be introduced.

Alternatively, it's possible to add @method annotations to an existing interface (see for instance b980121), to convey the fact that it's deprecated not to implement them. Do you think it makes sense to have implementations without those 2 methods?

[GromNaN]

Yes, it can be a simple approach since the methods are already implemented. We can argue that the new interface allows to detect the presence of the feature, but it can already be detected with method_exists, and relying on $class implements <newInterface> will skip all the actually existing versions.

The risk is using a method documented with @method in the interface but which is not actually implemented.

If we can create a new interface, that seems more solid to me.

[greg0ire]

If we can create a new interface, that seems more solid to me.

Can you detail what you mean by that? Will the new interface extend the old one? And if yes, should consumers then migrate to the new interface, and we drop the old one in the next major release? What's the plan for next major exactly?

[mbabker]

The risk is using a method documented with @method in the interface but which is not actually implemented.

Except, in the 3 maintained managers (ORM, MongoDB ODM, PHPCR ODM), the methods exist. They also exist in the archived CouchDB ODM's implementation, or if you want to go even further into the time machine, the OXM repo. It looks like the archived skeleton mapper and OrientDB ODM are the only implementations from Doctrine that didn't get these methods. Existing in 5 out of 7 cases to me makes a strong argument to just add it to the main interface.

If we can create a new interface, that seems more solid to me.

I don't think that's necessary as a consumer of doctrine/persistence (in both application and library code). If anything, I'd say that a new interface adds more work as you're still checking if the methods exist (either by checking for a new interface or a method_exists() fallback) until you only support whatever version that interface is introduced in, whereas adding them to the ClassMetadata interface formalizes something that exists in all maintained Doctrine implementations of the interface, and as you pointed out, simplifies the public APIs to not need to worry about internal refactorings.