Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49827
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.123 as permitted sender)
Message-ID: <4CA4EE37.7050109@sugarcrm.com>
Date: Thu, 30 Sep 2010 13:08:23 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Matthew Weier O'Phinney <weierophinney@php.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <AANLkTindUYYbqGBqFTa6Do85mxFRSUeob5dw6Npjki_A@mail.gmail.com> <4CA3A7EF.6000201@sugarcrm.com> <BF.72.21763.F9084AC4@pb1.pair.com> <4CA4D840.6050907@sugarcrm.com> <F3.69.04170.1C9E4AC4@pb1.pair.com>
In-Reply-To: <F3.69.04170.1C9E4AC4@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Bug in 5.3 __invoke() magic method?
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Using __call() for this, quite honestly, sucks. You have to define it in
> each and every class you write -- leading to code duplication -- or have
> all your classes inherit from a common object -- leading to an
> inheritance nightmare.

That's why we (will) have traits :)

> Additionally, there are huge performance implications. The most flexible
> variants utilize call_user_func_array() inside __call(), which, from
> profiling and benchmarking I've done, can be around 6x slower than
> simply calling a function.

On this level, performance considerations don't matter too much. 1ns and 
6ns are not that different, unless you are so CPU-bound that extra 
function call breaks it - in which case you should write an extension or 
do some caching.

> I think these can all be answered.
>
>   * Only dereference objects with __invoke() or closures; don't worry
>     about other callback types.

Why not? It's quite unobvious why object invocation should be so 
different from non-object invocation

>   * If __get resolves a property that's invokable, dereference it and
>     invoke it. Anything else, simply treat as was done before -- and
>     fallback to __call().
>     (That said, I realize where you're heading with this -- you now have
>     overhead when overloading, as you have to try first with __get then
>     __call, making resolution harder.)

Exactly. Any __call() should now be preceded with __get() - even though 
99% of them would never get anything useful from it. And there would be 
some very hard-to-debug bugs when __get would return something 
unexpected and you wouldn't really know what ends up being called.

> Closures and invokable objects blur the lines between properties and
> methods, making the "methods are different from properties" mantra more
> difficult to understand. My property is invokable -- why can't I invoke
> it without first casting it to a temporary variable?

You can. Just not by using method call syntax. By any other means - 
__invoke, call_user_function, etc. - you surely can.
Methods being different from properties is not a mantra, it's a fact. In 
Javascript it's the reverse - methods actually *are* the same as 
properties, but in PHP they are not.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227