Ability to define custom functions with callback instead of class name

[mnapoli]

Right now the only way to define custom DQL functions is by giving the class name, and Doctrine will create the class:

$config->addCustomNumericFunction('FOO', 'My\Custom\DqlFunction');

This is very limiting when the custom functions has dependencies, for example it can't be created by a DI container.

The approach I have taken here is very simple: it allows to define a callback instead of the class name: the callback will be called and it should return the instance:

$config->addCustomNumericFunction('FOO', function($funcName) {
    return new My\Custom\DqlFunction($funcName);
});

On a side note, I think it would be great to generalize that approach because currently there are a lot of places where the same constraints apply.

[doctrinebot]

Hello,

thank you for creating this pull request. I have automatically opened an issue
on our Jira Bug Tracker for you. See the issue link:

http://www.doctrine-project.org/jira/browse/DDC-3054

We use Jira to track the state of pull requests and the versions they got
included in.

[Ocramius]

What about

if (is_string($functName)) {
    $function = new $funcClass($funcName);
} else {
    $function = $funcClass($funcName);
}

Also, I'd change the naming from $funcClass to $functionName

[guilhermeblanco]

$function = is_string($functionName)
    ? new $functionClass($functionName)
    : $functionClass($functionName);

[Ocramius]

@mnapoli what is the use case for having a function coming from a container?

[mnapoli]

@Ocramius Regarding the use case, I have one with https://github.com/mnapoli/DoctrineTranslated:

SELECT e FROM MyEntity e WHERE TR(e.name) = 'hello'

Here TR is the "translation" function, which means the translation for the name must be "hello" in "the current locale". Given I use embedded objects, the TR function will turn the query into this:

SELECT e FROM MyEntity e WHERE e.name.en = 'hello'

(when the locale is en)

Have a look here: https://github.com/mnapoli/DoctrineTranslated/blob/master/src/Doctrine/TranslatedFunction.php

The test is here: https://github.com/mnapoli/DoctrineTranslated/blob/master/tests/DoctrineTest.php

The current locale must come from somewhere outside the DQL function. I don't want to get into too much details but basically the TR function will get the current locale (and the fallbacks) from the TranslationManager, which is a service.

But managing how objects are created, not just for custom functions, is a problem I regularly have. I know you have already told me (mailing list) "these should be very simple classes without dependencies" but I disagree, I have been limited by this so many times and given it can be fixed quite easily I would love to see this fixed.

[Ocramius]

@mnapoli I get what you are trying to do, I'm just not sure if it is a good idea... Not really convinced. On the other side, this is indeed ok as the constructor arguments for a function are not constrained by an interface (nor will).

[mnapoli]

I don't see a reason to put this kind of restriction. I would consider it bad practice in any library to create objects directly (I mean for extension points: objects provided by end-users) without providing an alternative.

[Ocramius]

That makes a whole lot of sense :)

[mnapoli]

Code updated with the remarks.

Anyone wants to give feedback too? I'd love to get this going, I really need it for DoctrineTranslated.

[mnapoli]

\o/ thanks!

[stof]

@mnapoli could you change it to call_user_func($functionClass, $functionName) to support non-closure callables on PHP 5.3 too ?

[mnapoli]

(fixed in #1031)