Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80908 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 95257 invoked from network); 20 Jan 2015 22:03:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Jan 2015 22:03:56 -0000 Authentication-Results: pb1.pair.com smtp.mail=dev@mabe.berlin; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=dev@mabe.berlin; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error) X-PHP-List-Original-Sender: dev@mabe.berlin X-Host-Fingerprint: 80.237.132.167 wp160.webpack.hosteurope.de Received: from [80.237.132.167] ([80.237.132.167:36445] helo=wp160.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 31/49-49046-AC0DEB45 for ; Tue, 20 Jan 2015 17:03:55 -0500 Received: from dslb-146-060-205-089.146.060.pools.vodafone-ip.de ([146.60.205.89] helo=[192.168.178.27]); authenticated by wp160.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1YDgtr-00057I-Ta; Tue, 20 Jan 2015 23:03:51 +0100 Message-ID: <54BED077.8020600@mabe.berlin> Date: Tue, 20 Jan 2015 23:02:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Nikita Popov CC: PHP internals References: <54BEC072.5000507@mabe.berlin> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;dev@mabe.berlin;1421791435;e0d1f5b2; Subject: Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls From: dev@mabe.berlin (Marc Bennewitz) On 20.01.2015 22:46, Nikita Popov wrote: > On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz > wrote: > > valid for call_user_func[_array] and callable type-hint but invalid > for for direct variable calls: > - string "MyClass::staticFunc" > - string "self::staticFunc" > - string "static::staticFunc" > - string "parent::func" > - string "parent::staticFunc" > > see http://3v4l.org/1oSO3 > > Thoughts ? > > > I would prefer deprecating this alternative notation instead of adding > more support for it. The [$class, $method] form is the canonical form we > support everywhere and which is consistent with the [$obj, $method] > callbacks. There's no point supporting another alternative notation, > especially if it was effectively unusable for a while now already. I don't think removing this is an option because of a big BC for no reason. Additionally the string alternative have some advantages: - better usable in configurations - return syntax of third argument of is_callable - ... > > Nikita Marc