Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.API page: TypedData::getParent()
The doc is not correct, returned value could be ComplexDataInterface too. Let's keep consistent with parent TypedDataInterface::getParent()
| Comment | File | Size | Author |
|---|---|---|---|
| typedData_doc.patch | 2.81 KB | smiletrl | |
Comments
Comment #1
BerdirNot sure how that ended up there, the @return should actually be on FieldItem(Interface?)
Comment #2
smiletrl CreditAttribution: smiletrl commentedI think the @return depends upon the the level of current typed data.
If it's a property of FieldItem, like the 'format', or 'value' of field_item:long_text, then @return for this property class should be FieldItem(Interface). Because FieldItemInterface extends ComplexDataInterface, we could say it will return ComplexDataInterface, which will be more generic to cover other use cases.
If it's a FieldItem, e.g., text, then @return will be the list class for this FieldItem, i.e, FieldItemListInterface. Because FieldItemListInterface extends ListInterface, we could say it returns ListInterface for the generic reason.
If it's a FieldItemList, then @return will be the entity this FieldItemList attached to. EntityInterface extends ComplexDataInterface, so it's already covered in above use case of property for FieldItem.
If it's an Entity, then it's alreay at the top level data tree. @return will be NULL.
Therefore, doc for TypedDataInterface::getParent() looks reasonable to me, but TypedData::getParent() asserts @return to be \Drupal\Core\Entity\Field\FieldItemListInterface, which is not correct then. I'm not sure I get your concern, does this answer your question:)?
Comment #3
BerdirYes. I'm not sure why the @return is *there*, for that specific class. 100% agree that this makes no sense.
What I meant is that if anywhere, then that should be on FieldItem, because that's where it makes sense. But we don't have to do it here.
We discussed TypedData & Field items/Entities and will very likely come up with a solution that doesn't require us to directly extend from it and give us the possibility to have useful methods and documentation on FieldItemInterface that will make sense for that.
Comment #4
amateescu CreditAttribution: amateescu commentedComment #5
jhodgdonFor future reference, the easiest way to get jhodgdon to notice an issue is to put it in the documentation component (if it's a docs issue, which this is). :) I'll get this committed next time I'm doing commits. Looks fine.
Comment #6
webchickI'm on the hunt for easy bits tonight, so yoink! :)
Committed and pushed to 8.x. Thanks!