- Issue created by @wim leers
- Assigned to ksere
- ๐จ๐ฆCanada ksere Montreal
I'll be taking this as part of a Symetris contribution workshop.
- Assigned to nbeaucage
- Merge request !6460Issue #3418678: Remove PrimitiveBase::setValue() because it is identical to... โ (Open) created by nbeaucage
- Issue was unassigned.
- Status changed to Needs work
9 months ago 7:11pm 5 February 2024 - ๐จ๐ฆCanada nbeaucage Montreal
The test pipeline seems to be failing without much information, so I'll leave this as "Needs work" for now.
Also I'm not sure if this requires a Change Record, feel free to ask for one if needed.
- Status changed to RTBC
9 months ago 2:04pm 8 February 2024 - ๐ง๐ชBelgium borisson_ Mechelen, ๐ง๐ช
it's only failing in the javascript tests, looks like a random failure to me. I think this is actually good to go.
- Status changed to Needs work
9 months ago 3:03pm 8 February 2024 - ๐ฌ๐งUnited Kingdom longwave UK
If we are going to do this we should at least remove
getValue()
as well, as that's also the same as the parent implementation. If this is the only change this doesn't need a change record, there is no functional change here, just removing useless code.But having said that, having the getter and setter in the abstract base class refer to a property that doesn't exist is a bit of a strange design, and PHPStan is already complaining about this:
message: "#^Access to an undefined property Drupal\\\\Core\\\\TypedData\\\\TypedData\\:\\:\\$value\\.$#" count: 2 path: lib/Drupal/Core/TypedData/TypedData.php
Would it be better to remove getValue/setValue from the abstract class and implement them only in PrimitiveBase? We would need to implement backward compatibility here though.
- ๐ฌ๐งUnited Kingdom longwave UK
Also this is a duplicate of ๐ Useless method overrides in \Drupal\Core\TypedData\PrimitiveBase and missing property definition in TypedData Needs work
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
Would it be better to remove getValue/setValue from the abstract class and implement them only in PrimitiveBase? We would need to implement backward compatibility here though.
That'd indeed be a BC break. That's why I proposed this.
The simpler and lower-risk change is to remove both
::setValue()
and::getValue()
, and define theprotected $value
property inabstract class TypedData
.P.S.: Sorry for not finding ๐ Useless method overrides in \Drupal\Core\TypedData\PrimitiveBase and missing property definition in TypedData Needs work ๐ฌ.
- ๐ฎ๐ณIndia kalpanajaiswal
Unwanted code has been removed based on the last comment.
- last update
9 months ago Patch Failed to Apply - First commit to issue fork.
- Status changed to Needs review
9 months ago 12:22pm 13 February 2024 - ๐ฎ๐ณIndia shalini_jha
Fixed Pipeline failure issues and added #10 changes in this Mr against 11.x .
Please review. - Status changed to Needs work
9 months ago 1:39pm 13 February 2024 - ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
Close, but not quite ๐ Too many changes, some of which constitute a BC break.
Also: we need to update the PHPStan baseline, that's what the MR pipeline is currently failing on. Some errors no longer need to be ignored! ๐
- ๐จ๐ฆCanada nbeaucage Montreal
I would like to propose we simply remove the superfluous getter and setter within PrimitiveBase. This would solve the adjustments requested by this issue. I took the liberty of reverting the previous commit, and having only the getter and setter removed. Please feel free to revert my revert if that should not have been done.
The rework related to having a base $value property within the TypedData base class can be addressed in the other related issue ( https://www.drupal.org/project/drupal/issues/3385629 ๐ Useless method overrides in \Drupal\Core\TypedData\PrimitiveBase and missing property definition in TypedData Needs work ), since it might be more complex than the fix that was proposed here.
For example, the \Drupal\Core\TypedData\Plugin\DataType\Map class, which also extends TypedData, does not possess nor makes use of a $value property, but instead uses a $values property (plural, since it's a key/value store of data).
So we can't really add a $value property to the base TypedData class, since it is not relevant to all of its extending children. Also note the comment at the top of the TypedData class:
/**
* The abstract base class for typed data.
*
* Classes deriving from this base class have to declare $value
* or override getValue() or setValue().
*
* @ingroup typed_data
*/In our current case, PrimitiveBase declares the $value property as instructed, while Map overrides the ::getValue() method from TypedData. Both solutions are following the defined instructions, so I would leave them as-is within this specific issue, while they could be addressed in the related issue instead.
What I usually do when implementing base classes for my teams is the following (which I am 100% open to discuss if it is a viable solution or not):
- Have a public getter method declared in an Interface (e.g. TypedDataInterface)
- Implement said public getter method in a base, abstract class (e.g. TypedData)
- No property defined in the base abstract class, but instead declare an abstract protected intermediary getter method (e.g. ::getValueProperty())
- The public getter method implemented in the base abstract class only calls the abstract protected intermediary getter method, not a property
- Thus, children of the base abstract class MUST implement the protected intermediary getter method, and customize it as needed
- In our case, PrimitiveBase would then declare its own $value property, since it is needed in its context, and then return it in the protected getter function
- The same logic can be used for the public and abstract protected setter methods, basically replacing $this->value by something such as $this->getValueProperty()
Anyway, those are my two cents!
Now, I am not sure what to do regarding the PHPStan baseline (where adjustments/updates should be made).
- Status changed to Needs review
8 months ago 6:16pm 5 March 2024 - Status changed to RTBC
8 months ago 2:48pm 15 March 2024 - ๐บ๐ธUnited States smustgrave
Can confirm that the setValue and getValue are the exact same as TypedData
So cleanup looks fine to me.
- Status changed to Needs work
8 months ago 11:49am 16 March 2024 - ๐ฌ๐งUnited Kingdom alexpott ๐ช๐บ๐
I think we should deprecate \Drupal\Core\TypedData\TypedData::getValue() and \Drupal\Core\TypedData\TypedData::setValue() and tell people to either extend PrimitiveBase or implement it themselves.
- First commit to issue fork.
- ๐ฎ๐ณIndia karanpagare
Addded the change as per #17 but i think we may need to fix php standards for that as well.
- ๐ง๐ชBelgium wim leers Ghent ๐ง๐ช๐ช๐บ
This still needs the deprecation #17 asked for.
- Assigned to magaki
- Issue was unassigned.
- Status changed to Needs review
4 months ago 9:25am 17 July 2024 - ๐ฏ๐ตJapan magaki
I added deprecations and tests and reverted the commit that removed the functions to deprecation.
However, PHPStan warns of making a deprecated call by adding the deprecations.
The following classes directly inherit TypedData and have no overridden function implementations.- core/lib/Drupal/Core/TypedData/Plugin/DataType/Any.php
- core/lib/Drupal/Core/Config/Schema/Element.php
- core/modules/layout_builder/src/Plugin/DataType/SectionData.php
- core/modules/system/tests/modules/entity_test/src/TypedData/ComputedString.php
- core/modules/text/src/TextProcessed.php
- core/tests/Drupal/Tests/Core/Plugin/Fixtures/Plugin/DataType/TestDataType.phpIf change it to inherit from PrimitiveBase, I should implement PrimitiveInterface::getCastedValue().
How should I fix it?
- Status changed to Needs work
4 months ago 1:25pm 17 July 2024 - ๐บ๐ธUnited States smustgrave
Need to make sure no code in core is calling the deprecated functions. So when we remove it'll be a simple delete.
- Status changed to Needs review
4 months ago 6:43am 18 July 2024 - ๐ฏ๐ตJapan magaki
I removed the methods from TypedData and reimplemented them in TypedData inherited classes that did not implement the method.
And, I removed ignoreErrors item from .phpstan-baseline.php since $value is no longer used in TypedData. - Status changed to RTBC
3 months ago 1:53pm 9 August 2024 - Status changed to Needs work
3 months ago 2:08am 10 August 2024 - ๐ฌ๐งUnited Kingdom catch
This is removing 29 lines of code to add 88 lines which are mostly duplicated, I think it needs more discussion. Why not a trait?
- ๐ฏ๐ตJapan magaki
We could use a Trait, but there are concerns.
PrimitiveBase::setValue uses properties ($name and $parent) defined in the parent TypedData class.
These properties should also be implemented in a new Trait, as the Trait defines the setValue function.
Since it is assumed that the Trait will be used by classes that inherit TypedData, classes that use the Trait will redefine the properties of TypedData.
Currently, there is no problem as the final values are the same and no errors have occurred.
However, if changes $name or $parent in TypedData in the future, the changes will no longer directly follow the properties in the Trait by redefinition, and the values โโof properties in classes that use the Trait may not be set appropriately.
Is this an unnecessary concern?