Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39594 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45062 invoked from network); 4 Aug 2008 04:57:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Aug 2008 04:57:20 -0000 Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 212.25.124.163 il-gw1.zend.com Windows 2000 SP4, XP SP1 Received: from [212.25.124.163] ([212.25.124.163:52989] helo=il-gw1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BE/A3-23035-F2C86984 for ; Mon, 04 Aug 2008 00:57:20 -0400 Received: from us-ex1.zend.com ([192.168.16.5]) by il-gw1.zend.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Aug 2008 07:58:01 +0300 Received: from [192.168.17.27] ([192.168.17.27]) by us-ex1.zend.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 Aug 2008 21:57:58 -0700 Message-ID: <48968C57.6070502@zend.com> Date: Sun, 03 Aug 2008 21:57:59 -0700 Organization: Zend Technologies User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Etienne Kneuss CC: PHP Internals List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Aug 2008 04:57:58.0510 (UTC) FILETIME=[AA1CE0E0:01C8F5EE] Subject: Re: [PHP-DEV] __invoke concerns From: stas@zend.com (Stanislav Malyshev) 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