Hi!
1) I don't believe that having it thrown as another of those magic
method is a good idea. Rather, I'd like to have it represented by an
interface: Invokable. That way, type hints/checks can be done in user
land in a sane matter:
We can have Invokable and even have Closure implement it, if there's
need, I see no problem with it.
However, I'm not sure we should *require* interface membership for
__invoke to work - I do not see any added value in this.
2) Do we really want __invoke's argument to be mapped to caller
arguments. Providing an array of arguments, ala __call(Static) sounds
more consistent.
More "consistent" with what? __call is different from __invoke - __call
is global interceptor (takes any function), __invoke is not. And you can
easily convert it to array with function_get_args().
3) Do we really want to allow both static and non-static versions of __invoke ?
class A { public static function __invoke($args) { .. }} $a = new A;
$a(); being a static call to __invoke doesn't make much sense to me.
I don't see how static __invoke may be useful. Anyone has a use case?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
