Problem

  • Calling entity_create('some_type') does not really tell developers that they get a SomeType entity back (aside from a @return EntityInterface).

Goal

  • Change entity type names, or at least the entity_create($type) argument, so that's more apparent with what kind of entity you are actually dealing with afterwards.

Related issues

This is debatable on many fronts, and might have large-scale implications, so let's discuss. ;)

Comments

I feel like this is related to #1380720: Rename entity "bundle" to "subtype" cause it only makes sense to me if we go with the #20 there (the "call it entity class instead of entity type" proposal).
Otherwise, the current approach seems better.

I can't say I'm really in favor of making the class name also the machine name if we do not have a way around that. For one, it means you can never change the class that is used for a given entity type, because its name is hard coded all over the system.

For another, pretty soon now, hopefully, those class names will be namespaced, and I really can't see anyone wanting to type entity_create('Drupal\Module\node\Node'); :-)

pretty soon now, hopefully, those class names will be namespaced, and I really can't see anyone wanting to type entity_create('Drupal\Module\node\Node');

Actually — wouldn't the namespacing allow us to have

  1. Node module registering Node as entity type, using the namespace Drupal\Module\node\Node by default
  2. NodeTNG module from contrib implementing hook_entity_info_alter() to re-route Node to Drupal\Module\node_tng\Node

(?) Or am I completely off and inane here? :)

Well the proposal here (as I understand it) would effectively mean that:

<?php
function node_entity_info() {
 
$return = array(
   
'node' => array(
     
'label' => t('Node'),
     
'controller class' => 'NodeController',
     
'class' => 'Node',
    ),
  );
  return
$return;
}
?>

becomes:

<?php
function node_entity_info() {
 
$return = array(
   
'Node' => array(
     
'label' => t('Node'),
     
'controller class' => 'NodeController',
    ),
  );
  return
$return;
}
?>

But that then means once namespaced, it's not 'Node' => array(...), but 'Drupal\Module\node\Node' => array(...). The class name becomes the key you look up on. That removes a fairly useful layer of abstraction, and means the key you type is longer.

What if it would become this though?

<?php
function node_entity_info() {
 
$return = array(
   
'Node' => array(
     
'label' => t('Node'),
     
'class' => 'Drupal\Module\node\Node',
     
'controller class' => 'Drupal\Module\node\NodeController',
    ),
  );
  return
$return;
}
?>

Perhaps I'm not making sense though, still not sure ;)

Well, then that is still an abstracted name because Node isn't the actual name of the class that gets used. And if someone hook_entity_alter()s the array and sets class to \Drupal\Module\mymodule\SillyNode, then you'll request "Node" and get back something with a base name of "SillyNode".

hm, I'm not really fond of that as it implies a direct relation between the entity type name and the used class, what isn't there (as crell points out).

Status:Active» Closed (won't fix)

Given #1497366: Introduce Plugin System to Core, 'taxonomy_term' needs likely to be considered as sort of a "plugin instance/definition name", which might map to TaxonomyTerm, but possibly also not.