Add ability to use custom method name in ClosureExpressionVisitor

[yvoyer]

This would enable the developper to control the naming of its methods instead of having to name it get or is.

Use case:

require_once 'vendor/autoload.php';

use Doctrine\Common\Collections\Criteria;
use Doctrine\Common\Collections\ArrayCollection;
use PHPUnit_Framework_Assert as Assert;

class Foo
{
    public function returnsTrue()
    {
        return true;
    }
}

$object = new Foo();
$collection = new ArrayCollection(array($object));
$criteria = Criteria::create()->andWhere(Criteria::expr()->eq('returnsTrue', true));
Assert::assertSame($object, $collection->matching($criteria)->first());

Before: would produce this error:

PHP Notice:  Undefined property: Foo::$returnsTrue in /home/yvoyer/git/warlord/vendor/doctrine/collections/lib/Doctrine/Common/Collections/Expr/ClosureExpressionVisitor.php on line 72
PHP Stack trace:
PHP   1. {main}() /home/yvoyer/git/warlord/test.php:0
PHP   2. Doctrine\Common\Collections\ArrayCollection->matching() /home/yvoyer/git/warlord/test.php:24
PHP   3. array_filter() /home/yvoyer/git/warlord/vendor/doctrine/collections/lib/Doctrine/Common/Collections/ArrayCollection.php:367
PHP   4. Doctrine\Common\Collections\Expr\ClosureExpressionVisitor->Doctrine\Common\Collections\Expr\{closure}() /home/yvoyer/git/warlord/vendor/doctrine/collections/lib/Doctrine/Common/Collections/ArrayCollection.php:367
PHP   5. Doctrine\Common\Collections\Expr\ClosureExpressionVisitor::getObjectFieldValue() /home/yvoyer/git/warlord/vendor/doctrine/collections/lib/Doctrine/Common/Collections/Expr/ClosureExpressionVisitor.php:115
PHP Fatal error:  Uncaught Failed asserting that false is identical to an object of class "Foo".

thrown in /home/yvoyer/git/warlord/vendor/phpunit/phpunit/src/Framework/Constraint.php on line 110

After: Applying the patch would resolve the problem, and the script will pass.

[yvoyer]

Relates to #60, #57, #29

[mikeSimonson]

@stof @Ocramius Of all the PRs that try to fix the non standard naming strategy ( #60, #57, #29 ), this one seems the least hairy and least problematic to me. What do you think ?

[mikeSimonson]

Ok. After having re read all the different threads, it looks like #57 was the only one that wouldn't break the sql generation. @yvoyer What do you think about closing this PR ?

[maresja1]

#57 is not general enough. Please consider at least this one. What does this break in terms of generating SQL?

[mikeSimonson]

@maresja1 https://github.com/doctrine/collections/pull/29#issuecomment-123747570

[maresja1]

@mikeSimonson I think it is already kind of broken, see my comment here - https://github.com/doctrine/collections/pull/57#issuecomment-234213200

When I call my field isCompany, it works prefectly fine when fetched from DB, but it does not work, when it's being used as ArrayCollection instantiated in the code, because it is trying to call getter getIsCompany or isIsCompany which does not exist.

[artursvonda]

This is an issue for us as we don't use get/is prefix for getters. And this breaks criteria on array collection.

By the way, the only issue for me here is that this could be considered breaking change as it suddenly will start matching new methods?