+1 from me; I guess we cannot support both for BC?

@schmittjoh We will support both until 2.3.

-1 on dropping virtual. There are many tools using the virtual naming as something that's "not actually part" of the referred structure or data.

• Oracle 11g uses virtual columns
• MariaDB 5.2 named them virtual columns
• Propel uses virtual columns
• dunno about Doctrine, but at least the users mailing list talks about virtual columns

@havvg This was the reason for choosing that name in the first place. The problem is that people can't apply their knowledge from databases here. They first have to learn how data mapping works in order to learn what "virtual" means in the form context. Once they know about data mapping, "inherit_data" should be much more intuitive.

+1, reasonable naming

-1, "inherit_data" does not sound much better to me. "Mixin" or "Trait" would probably be better than "Inherit" in term of OOP.

@vicb I don't see why mixin would be better. It is inheriting the data from the parent form.
The most similar thing I can think about is the inherit value for CSS rules, telling the browser to use the rule of the parent.

@vicb A virtual form is essentially the same as a form with

$builder->add('sub', 'form', array(
    'property_path' => '..',
));

only that this syntax doesn't (and can't) exist. So I really think that an option name related to data mapping should make it easier to understand (even if you like to think of such a form as mixin or trait).

@bschussek your comment made me think of something:

<?php
$builder->add('sub', 'form', array(
    'property_path' => '..',
));

but

<?php
$builder->include('form');

would be possible with a helper include()

but the include() helper could not be used in case of a collection of virtual forms (due to the delayed instantiation it has to be an option in such a case).