ContextDefinition::getDataDefinition() retrieves DataDefinitionInterface objects. Then it invokes setter methods on them that are not defined on the interface.
Option 1:
Per the
backward compatibility policy →
, this is viable and the easiest.
Break the API by adding the methods to the interface, assuming no one has implemented the interface directly without extending DataDefinition.
Option 2:
This should not be needed, as adding new methods to an interface does not break BC
Add a new MutableDataDefinitionInterface which contains the setters. DataDefinition then implements this interface, and we can properly check if setters are available.
Option 3:
To stay API compatible don't change the interface and introduce method_exists() calls instead?
Decide on option + Patch + test.
none.
Depends on the option chosen.
none.
Needs work
10.1 ✨
It is used to alert the maintainer(s) of a particular core subsystem that an issue significantly impacts their subsystem, and their signoff is needed (see the governance policy draft for more information). Also, if you use this tag, make sure the issue component is set to the correct subsystem. If an issue significantly impacts more than one subsystem, use needs framework manager review instead.
Used to track the progress of issues reviewed by the Drupal Needs Review Queue Initiative.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Can the MR be updated to 10.1 please
Also there were some open threads in MR 1577 that should be looked at.
https://www.drupal.org/docs/develop/standards/php/api-documentation-and-... →
All those @return static in the patch should really be @return $this