Replace explicit `__invoke` call with regular call syntax

[julienfalque]

Feature request

-$callable->__invoke();
+$callable();

-$this->callable->__invoke();
+($this->callable)();

Link to Discussion where feature request was formed

No response

Contribution Checks

• I have verified if this feature request was already discussed
• I am familiar with "Feature or bug?"

[mvorisek]

Is this feasible, are you sure __invoke cannot be any/unknown method?

[julienfalque]

What do you mean? As long as the __invoke() method exists, the object is callable as a function. The only case I see where this will fail is when __invoke() is not defined but __call() is. Although that seems unlikely, the fixer should be risky for that reason.

[mvorisek]

You are right - https://3v4l.org/fPaLC - 👍. I thought __invoke() to be present only on Closure.

[Wirone]

The only case I see where this will fail is when __invoke() is not defined but __call() is. Although that seems unlikely, the fixer should be risky for that reason.

It does not matter, __call() has different intent and usage. We can safely (and in non-risky way) change $obj->__invoke(/* args */) to shorter $obj(/* args */).

[mvorisek]

The only case I see where this will fail is when __invoke() is not defined but __call() is. Although that seems unlikely, the fixer should be risky for that reason.

It does not matter, __call() has different intent and usage. We can safely (and in non-risky way) change $obj->__invoke(/* args */) to shorter $obj(/* args */).

It matters - https://3v4l.org/AYFu3, but I am neutral if it should be risky or not.

[Wirone]

Ahhh, this way 😅. I think there are 2 possible paths:

• make a pretty dumb and risky fixer that will just change ->__invoke() to (), leaving responsibility for verifying it to the user
• make a context-aware, non-risky fixer that would change ->__invoke() to () only if we know the class being invoked and that class has __invoke() defined. BUT this is pretty much unachievable, because Fixer has context limited to a single file and most probably ->__invoke() is called outside of a invokable class, not inside of it. So I believe there are pretty low chances we can make it both safe and useful. We also don't support inheritance.

In general, seems like a job more for a Rector than Fixer.

[julienfalque]

IMO the fixer is pretty simple to implement, and since the risky situation is very unlikely, I think it's fine to have it in PHP CS Fixer.

[Wirone]

@julienfalque of course, I am not against this rule, I just think it will be risky anyway, since we just can't ensure proper context (including inheritance).

Side question: should the rule support 2-way standardisation? Or we consider using short invocation as a promoted standard?

[julienfalque]

Fixing from ($foo)() to $foo->__invoke() is much more risky than from $foo->__invoke() to ($foo)(): (almost) all objects with __invoke() method are callable, but a lot of callables are not objects with __invoke() method. I would only implement the latter.

[keradus]

@julienfalque in context of Wirone#5 (comment) , do you want to keep this ticket open ?

[julienfalque]

@keradus Yes, the situations are not the same. We may prefer to avoid (string) $foo in case $foo type changes and silently introduces unexpected casts: it's not very type safe. However, $foo() is only compatible with callable type, so static analysis can have you covered: callable acts like an interface.