Consider changing CKEditor5PluginElementsSubsetInterface to not extend CKEditor5PluginConfigurableInterface

If it's not configurable, how could it possibly determine what the relevant subset is if the signature is

public function getElementsSubset(): array;

?

Based on what input would it determine what the relevant element subset is? There's no input to the method, so it'd have to be hardcoded. And if it's hardcoded, then … the plugin definition never should have claimed a bigger set of elements is supported if it's hardcoding a subset of those elements?

I see your point.

I don't see the harm in the current approach.

I guess we could remove that extends, but it's just mean nonsensical implementations are possible. That'd be worse for DX I think? I agree with the principle of composable interfaces. But when certain compositions do not make sense, what's the value in supporting them just for purist sake?

IOW: I don't see the value in the proposed approach. Not yet, that is 🤓

Also, what are reasonable clients of this interface (aka callers)? The only sensible client is the CKEditor 5 module itself, isn't it?

I'm currently +! with @Wim Leers. I acknowledge the motivation behind wanting to make the interfaces independent, but I think the practical benefits of keeping the extends outweigh the conceptual benefits of removing it.

There's a steep learning curve in developing for CKEditor 5, and I support leveraging any opportunity where a bit of opinionated code guides the developer towards steps that will ultimately be necessary. CKEditor5PluginElementsSubsetInterface extending CKEditor5PluginConfigurableInterface saliently enforces (via errors/IDE) the addition of methods that will inevitably need to be there anyway. Not doing this removes the benefits of immediacy and turns this into something a that adds to the already strained cognitive load of a developer figuring out how to extend CKEditor 5 in Drupal.

There's also plenty of classes extending FormInterface that have empty submitForm methods, and I think that's fairly uncontroversial. I certainly appreciated it when I was learning the poorly documented Drupal 8 API.

I don't want anyone ordering soup to have to explicitly ask for a spoon. It adds inconvenience (and potential frustration) to request an item that is almost certainly necessary. While it's theoretically possible the customer might want to drink from the soup bowl, etc. those customers aren't offended by the presence of the spoon. However, customers being told they needed to request the spoon will almost always think less of the restaurant.

I'd almost RTBC this based on @bnjmnm's hilarious and surprisingly fitting metaphors alone 😆

All silliness aside, curious what you think, @effulgentsia! 😊

Back to @effulgentsia for review.