I think you can simply add the service id to the$types additionally to the class name. This way both work as alias and there is no BC break.

Updated. Ping @symfony/deciders

@webmozart I have a question. You say that when using PHP 5.5, the needed changes are minimal:

Before:

$form =$this->createFormBuilder()    ->add('name','text')    ->add('age','integer')    ->getForm();$form =$this->createForm(newAuthorType());

After:

useSymfony\Component\Form\Extension\Core\Type\TextType;useSymfony\Component\Form\Extension\Core\Type\IntegerType;useAppBundle\Form\Type\AuthorType;$form =$this->createFormBuilder()    ->add('name', TextType::class)    ->add('age', IntegerType::class)    ->getForm();$form =$this->createForm(AuthorType::class);

My question is: if you use PHP 5.3 or PHP 5.4, you should use the following?

$form =$this->createFormBuilder()    ->add('name','Symfony\Component\Form\Extension\Core\Type\TextType')    ->add('age','Symfony\Component\Form\Extension\Core\Type\IntegerType')    ->getForm();$form =$this->createForm('AppBundle\Form\Type\AuthorType');

@javiereguiluz yes

@javiereguiluz Exactly. However, passing "text" or similar type names is still supported until Symfony 3.0 (although you'll get deprecation notes). Symfony 3.0 has a higher minimum PHP version anyway so there this is not a problem anymore.

@webmozart the original idea of this change was to improve DX by getting rid of thegetName(). However, I find this change anti-DX because you now have to type a lot more.

@webmozart can you fix the SecurityBundle form login test failures ? These tests are passing on the current 2.8 branch

Does it possible use dynamic form names? Currently we are using inline editing for cities in grid:

$form =$this->container->get('form.factory')->createNamed(            CityInlineEditType::getNameForCity($city),newCityInlineEditType(),$city        );

Is this code still walid after this PR?

@Koc Sure, you can use any form name you like. However, thetype needs to be passed as FQCN, i.e.

$form =$this->container->get('form.factory')->createNamed(    CityInlineEditType::getNameForCity($city),    CityInlineEditType::class,$city);

@Koc this PR is abouttype names, not aboutforms names.

@webmozart how does this impact the block names in form themes ?

Is it still possible to use alias? What if you have a type and you want then use this with various dependencies? I have to extend my class to solve this problem?

@javiereguiluz That's FUD. As I've shown above, you are writing less code than before. As of using types in forms, instead of typing'text' (6 chars) you now typeTextT + ENTER and let the IDE do the rest. That's one character less + type safety.

@DavidBadura you should add the type as a service

<serviceid="my.type"class="Vendor\Type\MyType">    <tagname="form.type" />    <argumenttype="service"id="some.service.id" /></service>

and do something like this

$form =$this->createFormBuilder()    ->add('name', MyType::class)¿    ->getForm();

I think the old way of forcing people to implementgetName was NOT good for three reasons:

1. there is already a class name to identify it, meaning getName is redundant
2. as we know, naming things is hard. thus forcing people to invent a name just creates a burden
3. easily creates conflicting names

This is why I proposed to remove/deprecate this concept completely instead of just making it optional.
The new way also has another advantage: It makes codeself-documenting.
Writing/seeing code like$formBuilder->add('property', 'entity') is not expressive (what options are available, what doesentity do?), but$formBuilder->add('property', EntityType::class) is. It allows you to easily open the EntityType class to look at documention and exposed options.
So I think it is DX-friendly. IDEs could even go futher now and propose/autocomplete all classes in your project that implement FormTypeInterface when building a form. Such things wouldn't be easily possible to automate when using abstract names which are resolved at runtime.

The only disadvantage I see is that using the class name does not correspond to type extensions. Using a class name as reference (in contrast to an abstract name) makes people assume it's really just this class. But type extensions can do anything on top of it which somehow clashes with the object-oriented way of using a class name. But I think type extensions are not so common anyway (esp. in user-defined ones).

All in all, I'm 👍

The only disadvantage I see is that using the class name does not correspond to type extensions. Using a class name as reference (in contrast to an abstract name) makes people assume it's really just this class. But type extensions can do anything on top of it which somehow clashes with the object-oriented way of using a class name. But I think type extensions are not so common anyway (esp. in user-defined ones).

not only type extension but also type inheritance. but this is just a documentation thing IMO.

This looks really good. Thanks@webmozart.

Updated.

Thank you@webmozart.

with this change how will i do now that my Type has some dependency injection stuff as constructor or otherwise?

before i did this in service.yml:

mybundle.form.type.address:class:%mybundle.form.type.address.class%arguments:[ @mybundle.service.transformator_factory ]tags:            -{ name: form.type, alias: address }

the transformator_factory did return a DataTransformerInterface i did use for addModelTransformer
(i need that because ParamConverter did had problems with my Object because i need an object inside a object)

now does the FormBuilder respect my service definition, and if not how can i get that working again in future symfony 2.8+ or 3.0?

@Hanmac please open an issue, comments in closed PRs are hard to track

@Hanmac this works exactly as before (except that you don't need the alias anymore in the tag if you use only the 2.8+ API)