I am the maintainer of Payment, which has two major entity types: payments (content entities) and payment methods (config entities). For the next version of the project, I would like both entity types to be of a different class if they are of a different subtype (e.g. bundle). The reason for this is that, a payment for a Commerce Order and a payment for a donation form may need different properties or even functionality, similar to that PayPal or Authorize.net payment methods need it.
What has been suggested to me on IRC is that instead of using per-bundle classes (which at the moment is not possible), I should make every payment and payment method type a different entity type. The problem with this approach is
- Conceptually: it makes a payment method of type Foo look fundamentally different from a method of type Bar, even though the entities themselves are for the most part identical.
- Functionally: It will no longer be possible to use the existing API features on *any* payment or payment method. Payment method list controllers will only work for payment methods of the same subtype, for instance.
As far as I can see now, the major problem in the current situation is entity_create(), which does not allow entities to be created based on subclasses. Doing $entity = new DrupalCommercePayment() instead of $entity = entity_create('payment'); would solve most, if not all of my issues. If that is not possible, a, perhaps more complex, solution is to allow bundles to be of a different class. However, as bundles were only meant to allow a different configuration to be applied to entities, this may actually make DX worse.
I'd like to know what people with more entity API experience think of this problem.