Problem/Motivation
Currently we have the abstract classes Entity, ContentEntityBase and ConfigEntityBase. Both ContentEntityBase and ConfigEntityBase extend from Entity. The naming of the abstract class Entity is inconsistent with the naming of the other classes.
We use the *Base naming convention at many places - for example WidgetBase, EntityDisplayBase, EntityReferenceFormatterBase, FormatterBase and many others ...
Proposed resolution
- Rename Entity to EntityBase.
- Provide a class Entity in the same namespace for backwards compatibility, but flag it as deprecated.
Remaining tasks
Review.
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | 1883744-25.patch | 40.88 KB | hchonov |
Comments
Comment #1
tim.plunkettYes.
However, by our coding standard, we'd have to rename it EntityBase.
Comment #2
xjmSee title. :)
Comment #3
tim.plunkettRight. Also, half of our entity types inherit from ConfigEntityBase anyway, which is properly abstract.
Comment #4
berdirIt is abstract now, but hasn't been renamed. No idea if we still want to do that?
Comment #10
hchonovI think that it still makes sense doing this as we have ContentEntityBase and ConfigEntityBase both extending from the abstract class Entity. I've done this in the attached patch.
Comment #11
hchonovComment #14
hchonovComment #16
hchonovThat should be it.
Comment #17
borisson_We should probably add a change notice as well?
Comment #18
joachim commentedThe IS doesn't seem related to the issue title.
+1 on the change record.
Comment #19
hchonovI've updated the issue summary and created a draft change record - https://www.drupal.org/node/3021808
Comment #20
hchonovComment #21
borisson_Looks done, the tests all pass and we have a cr that explains why and how. Great work!
Comment #22
tim.plunkettAs per https://www.drupal.org/core/deprecation#how this needs a
@trigger_errorto fire when a class extendsEntityinstead ofEntityBaseComment #23
hchonovI've added the @trigger_error. No other changes beside that. There is no diff, as I had to re-roll the patch.
Comment #24
tstoecklerI think this should be intended two spaces.
Also if the patch were rolled with
-CI think it would be quite a bit smaller.Also still needs a test for the deprecation per #22.
Comment #25
hchonovI wasn't sure about how to prepare a test and what I've tried didn't worked, because if we create a new class that extends from the deprecated class
Entitythen the deprecation will be triggered by the autoloader before the test itself.I've talked with @tstoeckler and he found a solution by using an anonymous class. However anonymous classes are supported only in PHP 7. As we still support PHP 5.6. we both agreed that a test case isn't necessary in this case.
P.S: I wasn't able to find any similar test in core as well, so it looks like we don't offer tests for deprecated classes.
I've prepared the new patch with the
-Coption. Thank you, @tstoeckler for the suggestion!Comment #26
tstoecklerThanks, this looks good to me!
As is mentioned in #25 I really don't see a way for us to test this using our standard mechanisms.
I think that is supposed to say "tests for deprecated abstract classes", as that is what is causing the problem here. Most of the deprecated abstract classes are tests themselves, for which we generally don't add tests, and I couldn't find any deprecation test for any other abstract class either. For example
\Drupal\migrate\Plugin\migrate\process\DedupeBase, doesn't have a corresponding deprecation test.Comment #27
hchonovYes, this is what I've meant. Thank you for correcting me and explaining it further! :).
Comment #28
alexpottDeprecation messages should refer to git tags and real releases not branches. And we need to add an @see to the change record. Fixed on commit.
Comment #29
alexpottCommitted 47dab9a and pushed to 8.7.x. Thanks!
Comment #32
quietone commentedpublish the change record