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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to