IMHO you should use instead:

$this->resolver->setDefault('foo', \Closure::fromCallable([$object, 'resolve']));

See discussion about this topic in #28129.

Thank you @yceruto, I missed this issue.

While I understand the arguments against in linked issue, I'm not pretty much convinced myself here, and some mates were expecting this to work. As soon as the ambiguity is solved by the typehint check and thus cannot lead to any weird situation (nor BC break), this seems fine to me.

I can't remember the option(s) for which we dropped callables in the past mentioned by @xabbuh, but I suspect it's about #17993 which was a slighlty different problem (though we could still ignore callable strings here IMHO).

This PR was motivated by seeing people & myself expecting it to work this way at first glance. Anyway, the alternative is short and simple. Let's reject & close this PR if this still does not make sense to you & the community.

Reading the linked issue, this is not about making sense or not: there are technical arguments against (BC break by ambiguity).

👎 for this reason (without trying to discuss anything else :) )

The technical arguments expressed in #17993 are about setAllowedValues and are mitigated here by the fact we're talking about setDefault for which we already ignore any signature not matching the Options typehint requirement for the first argument.

How would you decide whether the user wanted to use a string or a callable if the string represents both?

@xabbuh : I'd suggest to remove the callable strings support from this PR anyway. Does not seem much common to me and would be consistent with #17993.
But even if we don't, to answer your question: the same way it is for closures right now, i.e we check the first arg typehint.

• If it's Options, it's a lazy default value.
• If not, it is used directly as default value.

Alright. No new approval and still a -1 from a core team member. Let's close :)