[HttpFoundation] Deprecated count() and \Countable
merged branch drak/flashcountpt2 (PR #6443)

This PR was merged into the master branch.

Commits
-------

0cf9fcb [HttpFoundation] Deprecated count() and \Countable

Discussion
----------

[HttpFoundation] Deprecated count() and \Countable

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #6408
Todo: -
License of the code: MIT
Documentation PR: -

The docblock is done in #6423 so will be merged up.

---------------------------------------------------------------------------

by stloyd at 2013-01-07T11:19:20Z

@fabpot ping

---------------------------------------------------------------------------

by drak at 2013-01-07T11:22:54Z

This should be OK for merge as the solution was agreed with @fabpot before making the PR.

---------------------------------------------------------------------------

by fabpot at 2013-01-07T11:24:50Z

@drak Can you add an entry in the CHANGELOG stating that this is a BC break?

---------------------------------------------------------------------------

by drak at 2013-01-07T15:31:21Z

@fabpot - There doesnt seem to be a CHANGELOG-2.2 in the master branch... where should I place the information?

---------------------------------------------------------------------------

by Tobion at 2013-01-07T15:46:25Z

@drak just in the CHANGELOG under the 2.2. header

---------------------------------------------------------------------------

by fabpot at 2013-01-07T15:48:43Z

Here: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/CHANGELOG.md

---------------------------------------------------------------------------

by drak at 2013-01-07T15:48:45Z

@Tobion - thanks, I forgot it's in the package root, not the repo root. :)

---------------------------------------------------------------------------

by drak at 2013-01-07T15:52:37Z

@fabpot - updated changelog, squashed  and rebased.
[Form] Introduced base ExceptionInterface
[Form] Protected methods in FormConfigBuilder and FormBuilder from being called when it is turned into a FormConfigInterface instance
merged branch bschussek/issue6558_2 (PR #6580)

This PR was merged into the master branch.

Commits
-------

bcc5552 [Form] Protected methods in FormConfigBuilder and FormBuilder from being called when it is turned into a FormConfigInterface instance
fee1bf5 [Form] Introduced base ExceptionInterface

Discussion
----------

[Form] Protected methods in FormConfigBuilder and FormBuilder

Bug fix: yes
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -

When a form is created, a `FormConfigInterface` instance is passed to the constructor of `Form` and then accessible via `getConfig()`. For performance reasons, `FormBuilder` also implements `FormConfigInterface` and is passed here directly instead of copying its values to a new `FormConfig` instance, although protected from further modifications.

In addition to the already existing guard clauses in the setters, this PR adds guard clauses to the getters of `FormBuilder` to prevent misuse of the "config" object giving unexpected results.

Additionally, this PR introduces first improvements of the form's `Exception\` namespace as described in  #6549.

---------------------------------------------------------------------------

by mvrhov at 2013-01-05T18:19:04Z

@bschussek I don't have the time to review this one, but please do not over optimize. We do a lot of weird things. e.g. I have the following code in one of my models.

```php
public function validateEmail(ExecutionContextInterface $context)
{
    if ((null !== $this->product) && (in_array($this->product->getType(), array(ProductTypeEnum::Software, ProductTypeEnum::Subscription)))) {
        /** @var $form Form */
        $form = $context->getRoot();
        if (($form instanceof Form) && ('foo' == $form->getConfig()->getOption('app_name'))) {
            $context->validate($this, 'email', 'Email');
        }
    }
}
```

---------------------------------------------------------------------------

by bschussek at 2013-01-05T18:46:17Z

@mvrhov Absolutely no problem. Most people will use methods from `FormConfigInterface` on the result of `getConfig()`, because that's the type hinted return value, and that's the way it should be. I don't even know how many people are aware that `getConfig()` returns the builder object.

This PR is for rare cases where people write forward-incompatible hacks by accessing `FormBuilder` methods like `get()`, `getParent()` or the like on `getConfig()` (I don't know why anyone would do this, but you never know...)

---------------------------------------------------------------------------

by vicb at 2013-01-07T11:08:34Z

> Backwards compatibility break: no

Really ?

---------------------------------------------------------------------------

by vicb at 2013-01-07T12:26:22Z

Changing `FormException` from a class to an interface is a BC break (`new FormException()`)

---------------------------------------------------------------------------

by bschussek at 2013-01-07T12:41:20Z

@vicb Fair enough ;) I adapted the CHANGELOG and UPGRADE-2.2.

---------------------------------------------------------------------------

by fabpot at 2013-01-07T15:50:03Z

This PR break the tests.

---------------------------------------------------------------------------

by bschussek at 2013-01-07T15:50:34Z

I just fixed them and they run on my computer. I'm not sure why Travis fails again.

---------------------------------------------------------------------------

by bschussek at 2013-01-07T15:56:41Z

Travis merged the wrong commit. It merged 42c8987f350650a42d8c968d32cde50fc5d548c0 - see the merge commit here 766f7fe958ea69a302bed6298e55a3001a51e2b8 - when it should have merged cd3f4f9dfe43a526c23f30e16354ff11489b9db1.