Re: __invoke concerns

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 stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com