API page: TypedData::getParent()

The doc is not correct, returned value could be ComplexDataInterface too. Let's keep consistent with parent TypedDataInterface::getParent()

Files: 
CommentFileSizeAuthor
typedData_doc.patch2.81 KBsmiletrl
PASSED: [[SimpleTest]]: [MySQL] 58,880 pass(es).
[ View ]

Comments

Not sure how that ended up there, the @return should actually be on FieldItem(Interface?)

I 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:)?

Status:Needs review» Reviewed & tested by the community

Yes. 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.

Component:field system» typed data system

Component:typed data system» documentation

For 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.

Status:Reviewed & tested by the community» Fixed

I'm on the hunt for easy bits tonight, so yoink! :)

Committed and pushed to 8.x. Thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.