You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like Drupal 8 missed out on an opportunity to greatly clarify the architecture of entities by flipping the data structure and abstractions. Instead of class-specific identifiers for common properties (nid, uid, tid...), all of the entities should have called common properties the same thing (id).
And then instead of having an abstraction layer to standardize the data model, have a standard data model as the core, and provide an abstraction layer for backwards compatibility. So if you go looking for $node->nid, it returns the value of the id property.
The text was updated successfully, but these errors were encountered:
So if you go looking for $node->nid, it returns the value of the id property.
This is possible but I've been leery of it in the past. In order to do this, you'd need to use PHP's magic methods for __get() and __set(). The node object wouldn't actually have a "nid" property at all, but when checked or set, the magic methods would get called and route to the property that actually does exist.
I've got two issues in particular:
They're called "magic methods" for a reason, they're not particularly intuitive. It can be confusing when you $print->nid and get a value, but when you print_r($node) there is no nid value.
Using magic methods for get/set probably has some overhead associated with it. If it were used extensively, we could introduce performance issues that would be impossible if we only used real properties instead of magically mapped ones.
Somewhat less of an issue but still a concern, right now our internal properties have at least a small amount of indication as to what they are (nid, tid, uid, etc) and these are mapped in database columns. If we just made everything "id", you'd expect the database columns to match. But that would have problems where tables need multiple IDs, e.g. the taxonomy_index table has both nid and tid. So ultimately, you'd probably leave the database schema alone, but then need to deal with mapping the id property to whatever it is in the database.
I'm going to take a gamble and close this due to lack of consensus and interest. But do feel free to re-open (preferably with the 'needs feedback' label) if you'd like to discuss further.
It seems like Drupal 8 missed out on an opportunity to greatly clarify the architecture of entities by flipping the data structure and abstractions. Instead of class-specific identifiers for common properties (nid, uid, tid...), all of the entities should have called common properties the same thing (id).
And then instead of having an abstraction layer to standardize the data model, have a standard data model as the core, and provide an abstraction layer for backwards compatibility. So if you go looking for $node->nid, it returns the value of the id property.
The text was updated successfully, but these errors were encountered: