Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39566
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Sun, 3 Aug 2008 13:47:09 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <14630901.20080803134709@marcus-boerger.de>
To: "Etienne Kneuss" <colder@php.net>
CC: "PHP Internals List" <internals@lists.php.net>
In-Reply-To: <e666c3890808021036p58de549as422bec8471b7a992@mail.gmail.com>
References: <e666c3890808021036p58de549as422bec8471b7a992@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] __invoke concerns
From: helly@php.net (Marcus Boerger)

Hello Etienne,

Saturday, August 2, 2008, 7:36:23 PM, you wrote:

> Hi,

> this is probably not the best time to raise concerns about __invoke
> (closures) now that alpha1 is already realeased, but I believe it's
> worth it.

Actually it is the best time, well earlier would probably have been even
better. But seriously, the reason for an extended alpha phase is testing
and adjusting features if they do not behave as we like.

> 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:

> function foo(Invokable $obj) {
>     $obj();
> }

> if ($foo instanceof Invokable) $foo();

> etc..

Invokable sounds fine with me. It would be like Traversable. We don't
use Interfaces for much other stuff but imo we should.

> 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.
> class A { public function __invoke($arg) {var_dump($arg); }} $a = new
> A; $a(1,2); // int(1), currently. IMHO it should be array(1,2)

Of course not this must be fixed. After all we have invocation by
reflection with and without array. And this would be so badly inconsistent.
Which reminds me of writing a mail about the new inconsistencies in 5.3.


> 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 hope these issues can be discussed and maybe addressed before a
> final 5.3 release. I'm willing to do patches for all three concerns if
> I sense a positive feeling towards this.

> Regards,

> -- 
> Etienne Kneuss
> http://www.colder.ch

> Men never do evil so completely and cheerfully as
> when they do it from a religious conviction.
> -- Pascal




Best regards,
 Marcus