I am working on Sonata Project migration to work on symfony2.8 and symfony3.0. I get an architectural issue with the new method signature for the FormFactory. The type must be a FQCN, the FQCN has one major drawback, you have a 1:1 relation between the type and the class/instance. With the previous signature you have a N:N relation between types and the class, ie you can have different types handled by the same class but with different instance configurations.

With sf2.7,

new Symfony\Component\Form\Extension\DependencyInjection\DependencyInjectionExtension($this, array(
'sonata_classification_api_form_category' => 'sonata.classification.api.form.type.category', 
'sonata_classification_api_form_collection' => 'sonata.classification.api.form.type.collection', 
'sonata_classification_api_form_tag' => 'sonata.classification.api.form.type.tag', 
'sonata_classification_api_form_context' => 'sonata.classification.api.form.type.context',
);

The class behind the service is Sonata\CoreBundle\Form\Type\DoctrineORMSerializationType with different configurations per instance...

With > SF2.8:

new Symfony\Component\Form\Extension\DependencyInjection\DependencyInjectionExtension($this, array(
'Sonata\CoreBundle\Form\Type\DoctrineORMSerializationType' => 'sonata_classification_api_form_context' );

Of course, we are loosing definitions as the FQCN overlap keys. Is the best practice is to create a class per type ? If so we are loosing the benefit of OOP.

This change make very hard to have one bundle version working with Symfony 2.7, 2.8 and 3.0. And I don't see any benefit of it.

Can you explain or point to the valid PR which explain this choice?