Should abstract prototypes be allowed?

[leogr]

Currently, through the ServiceLocatorStrategy, it's possibile to implement a model that can handle objects of different types. All those classes must extend the declared class of the object prototype; sometimes this mechanism is called "virtual collection".

This feature allows to store objects into the persistence layer like the class inheritance mechanism does to represent objects at runtime.

Because only one object prototype is required by the result set and it must be passed as an instantiated object, there's no way to use an abstract class (or better an interface) as prototype for a model.

When a developer uses a set of concrete classes extending the same abstract class or implementing the same interface it can be useful to use an abstract class (or better an interface).

Question

Should components accept also a string (i.e. the abstract class/interface name) in order to enforce the type check without passing an already instantiated prototype?

Anyway, it could have a large impact on the current code, because a lot of functionalities rely on the object prototype instance (i.e., checking for HydratorAwareInterface and InputFilterAwareInterface, cloning the object prototype to build new object, hydrating/extracting embedded objects and so on).

I'm looking for better solutions in order. Any ideas?

[leodido]

I suspect that accepting also string representing abstract classes or interfaces will have huge impact on the code base - e.g., on the retrieving of hydrators and input filters.

Currently I vote no.

[leogr]

I agree too. Postponed.

Defining an interface that do not allow object to be saved, could be an alternative.