Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39580 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89903 invoked from network); 3 Aug 2008 22:03:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Aug 2008 22:03:07 -0000 Authentication-Results: pb1.pair.com header.from=ekneuss@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=ekneuss@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.46.31 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: ekneuss@gmail.com X-Host-Fingerprint: 74.125.46.31 yw-out-2324.google.com Received: from [74.125.46.31] ([74.125.46.31:57074] helo=yw-out-2324.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 22/16-50899-91B26984 for ; Sun, 03 Aug 2008 18:03:05 -0400 Received: by yw-out-2324.google.com with SMTP id 5so933797ywb.83 for ; Sun, 03 Aug 2008 15:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=yiuEnvdnOfqP4W9r4n6k5we1qb42dovYtZV8hsEbO+U=; b=sUJYQVMftE4WzmXmutCssz+1i6Xvno/1H8IiPDS1okgk4K8Ia2Gvn/W9Ct7ZB8hQI0 fSzSmoAtkBYJHBHoKD6yk860c9+NePYromgerlkOx9ijy9yXSoq6H4mEjw+Qb45z1RS/ 9HOyWyB6pAwz8MZBObtknK6fmWNg/IFn0k73Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=pXvnPhi96WQcOly+Qkq316HPI6qbgyfT6ULFYVW7CCvmHWOWwjs4in6L6ta2M4DNSz 5kHakiBZF+a9nhEsUmaUzEicK8RKuNqx0uZg0ypz8v22dHfr3dusUQPxpetSOV5nVqaF zPL2+oGWrlkHcxeEwU7kF2NTre6hQntZOwNyw= Received: by 10.150.98.18 with SMTP id v18mr7122390ybb.114.1217800981546; Sun, 03 Aug 2008 15:03:01 -0700 (PDT) Received: by 10.150.197.14 with HTTP; Sun, 3 Aug 2008 15:03:01 -0700 (PDT) Message-ID: Date: Mon, 4 Aug 2008 00:03:01 +0200 Sender: ekneuss@gmail.com To: "PHP Internals List" , "Marcus Boerger" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: f1027b6315894338 Subject: Re: __invoke concerns From: colder@php.net ("Etienne Kneuss") Hello, On Sat, Aug 2, 2008 at 7:36 PM, Etienne Kneuss 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. > > 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.. > > 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) > > > 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 > After looking deeper into it, I noticed that this interface brings a lot of problems: 1) With the interface, the prototype is fixed. Which means that the following are no longer possible: Class A { public function &__invoke(&$a, $b, $c) { return $a; } } $a = new A; $e =& $a($b,$c, $d); 2) __invoke($args) seems more consistent, and would give a consistent prototype, but 2.1) references are no longer possible (1) 2.2) __invoke of actual closures/lambdas needs to map parameters for $a = function($b,$c){}; to work properly. I don't believe $cl = function($args){..} is something we want So, with those counter-concerns in mind, this Invokable interface is no longer implementable, IMO. However, I'd still like to make closures more flexible and internals-friendly by implementing zend_get_closure as a handler. The only (tiny) issue here is that we export a bit more closure-material in the engine, and it's no longer so much self-contained in zend_closures. Patches: http://patches.colder.ch/Zend/zend_get_closure_handler_53.patch?markup http://patches.colder.ch/Zend/zend_get_closure_handler_HEAD.patch?markup ps: this patches also expose the __invoke method for reflection. (Or is there an actual reason behind not exposing it? ) -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal