# __call overload detection

- Thread: https://externals.io/message/21374
- Original archive: https://news-web.php.net/php.internals/21374
- Started by Andrew Yochum on 2006-01-03T20:57:28+00:00
- Messages: 44
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/21374.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #21374 — Andrew Yochum — 2006-01-03T20:57:28+00:00

URL: https://externals.io/message/21374#21374

Currently there is no way to detect if the __call overloads a particular
method.  Property overloading has __isset now in 5.1 - maybe for method
overloading the equivalent should be something like __iscallable.  Maybe
method_exists should remain as is, as the method won't ever really exist
but is_callable would/could use it, or perhaps some new function.

Is this a reasonable request?  Thoughts?

Regards,
Andrew
-- 
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

---

## #21375 — Andrew Yochum — 2006-01-03T21:33:32+00:00

URL: https://externals.io/message/21374#21375

Hi Marcus,


> Hello Andrew,
> 
>   right now you can use reflection.
> 
> marcus

The reflection APIs do not help I believe.  Consider that one may only
want __call to respond to a computable set of overloaded method names.
Right now, is_callable returns true for any requested method if __call
is implemented by the object.  Unless I have missed some magic that the
Reflection APIs can do, they don't apply here.

Consider the following:
    class a {
        var $callables = array('foo');
        function __call($name, $args) {
            if ($this->__is_callable($name)) return 'good call';
            else return 'bad call';
        }
        function __is_callable($name) {
            return in_array($name, $this->callables);
        }
    }

    $a = new a();
    print "is_callable: " . is_callable(array($a,'foo'),false, $callable) . " as $callable \n";
    // prints: is_callable: 1 as a::foo
    // OK
    print "is_callable: " . is_callable(array($a,'bar'),false, $callable) . " as $callable \n";
    // result: is_callable: 1 as a::bar
    // desired: is_callable: 0 as 
    // or some other similar behavior if __is_callable is implemented

If one were to implement a reflection-like method called __iscallable,
you could get this functionality, but couldn't count on other's code
using the same convention.  Another downside to doing it yourself is
that every call to a method must first check __is_callable - this could
be handled by the language upon a method call.  If I feel it would be a
good idea to implement this in the lanaguage for standardization and
simplicity.

Regards,
Andrew

-- 
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

---

## #21376 — Marcus Boerger — 2006-01-03T21:50:24+00:00

URL: https://externals.io/message/21374#21376 · In reply to: #21375

Hello Andrew,

  you do not implement __call for a method but you deal with the method name
in any sense you like, which also includes ignoring specific __call
invocations. Reflection gives you the ability to check whetehr a function
is being physically available. If you need more it is up to you to provide
the infrastructure. Remember we will not in anyway allow __call to handle
inheritance.

regards
marcus

Tuesday, January 3, 2006, 10:33:32 PM, you wrote:

> Hi Marcus,

> 
> > […]

> The reflection APIs do not help I believe.  Consider that one may only
> want __call to respond to a computable set of overloaded method names.
> Right now, is_callable returns true for any requested method if __call
> is implemented by the object.  Unless I have missed some magic that the
> Reflection APIs can do, they don't apply here.

> Consider the following:
>     class a {
>         var $callables = array('foo');
>         function __call($name, $args) {
>             if ($this->__is_callable($name)) return 'good call';
>             else return 'bad call';
>         }
>         function __is_callable($name) {
>             return in_array($name, $this->callables);
>         }
>     }

>     $a = new a();
>     print "is_callable: " . is_callable(array($a,'foo'),false, $callable) . " as $callable \n";
>     // prints: is_callable: 1 as a::foo
>     // OK
>     print "is_callable: " . is_callable(array($a,'bar'),false, $callable) . " as $callable \n";
>     // result: is_callable: 1 as a::bar
>     // desired: is_callable: 0 as 
>     // or some other similar behavior if __is_callable is implemented

> If one were to implement a reflection-like method called __iscallable,
> you could get this functionality, but couldn't count on other's code
> using the same convention.  Another downside to doing it yourself is
> that every call to a method must first check __is_callable - this could
> be handled by the language upon a method call.  If I feel it would be a
> good idea to implement this in the lanaguage for standardization and
> simplicity.

> Regards,
> Andrew




Best regards,
 Marcus

---

## #21378 — Mike Naberezny — 2006-01-03T23:44:33+00:00

URL: https://externals.io/message/21374#21378 · In reply to: #21375

Hi Andrew,

Andrew Yochum wrote:
> Consider that one may only
> want __call to respond to a computable set of overloaded method names.

Usually, this is done by something like this:

<?php
class Test {
     public function __call($method, $args) {
         switch ($method) {
             case 'method_name_1':
                 // handle method_name_1
                 break;
             case 'method_name_2':
                 // handle method_name_2
                 break;
             default:
                 throw new Exception('Call to undefined method ' . __CLASS__ . 
'::' . $method . '()');
          }
     }
}

$t = new Test();
$t->nonexistant();
?>

I see your point with detection by something like __is_callable(), although I 
  can't personally think of a place where I'd use it.

Mike

---

## #21379 — Andi Gutmans — 2006-01-03T23:45:23+00:00

URL: https://externals.io/message/21374#21379 · In reply to: #21374

Why not just use Reflection API to check? It seems quite trivial to do so.

At 12:57 PM 1/3/2006, Andrew Yochum wrote:
>Currently there is no way to detect if the __call overloads a particular
>method.  Property overloading has __isset now in 5.1 - maybe for method
>overloading the equivalent should be something like __iscallable.  Maybe
>method_exists should remain as is, as the method won't ever really exist
>but is_callable would/could use it, or perhaps some new function.
>
>Is this a reasonable request?  Thoughts?
>
>Regards,
>Andrew
>--
>Andrew Yochum
>Plexpod
>andrew@plexpod.com
>718-360-0879

---

## #21380 — Mike Naberezny — 2006-01-03T23:54:21+00:00

URL: https://externals.io/message/21374#21380 · In reply to: #21376

Marcus Boerger wrote:
> If you need more it is up to you to provide
> the infrastructure. Remember we will not in anyway allow __call to handle
> inheritance.

Hi Marcus,

If one is determined enough, at least visibility can be faked by exception 
trace introspection.  Below demonstrates protected, replace __CLASS__ with 
get_class($this) for private.  I see very little or no real world application 
for this and the procedure is quite expensive.

<?php
class Test {
     public function __construct() {
         // demo, should echo "hello"
         echo $this->nonexistant;
     }

     public function __get($offset) {
         try {
             throw new Exception();
         } catch (Exception $e) {
             $trace = $e->getTrace();
             $caller = isset($trace[2]['class']) ? $trace[2]['class'] : null;
             if ($caller === null
                 || $caller != __CLASS__
                 && !is_subclass_of($caller, __CLASS__)) {
                     throw new Exception('Access to protected ' .__CLASS__. 
'::' .$offset. ' from context '. $caller);
             }
         }

         return 'hello';
     }
}

$t = new Test();           // hello
echo $t->nonexistant;      // exception
?>

Mike

---

## #21381 — Marcus Boerger — 2006-01-04T00:05:48+00:00

URL: https://externals.io/message/21374#21381 · In reply to: #21379

Hello Andi,

  the point is probably that there is no way in determinig whether a
certain function is supposed to work prior to calling it.

regards
marcus

Wednesday, January 4, 2006, 12:45:23 AM, you wrote:

> Why not just use Reflection API to check? It seems quite trivial to do so.

> At 12:57 PM 1/3/2006, Andrew Yochum wrote:
> > […]




Best regards,
 Marcus

---

## #21382 — Andrew Yochum — 2006-01-04T00:37:26+00:00

URL: https://externals.io/message/21374#21382 · In reply to: #21376

Hi Marcus,


> Hello Andrew,
> 
>   you do not implement __call for a method but you deal with the method name
> in any sense you like, which also includes ignoring specific __call
> invocations. Reflection gives you the ability to check whetehr a function
> is being physically available. If you need more it is up to you to provide
> the infrastructure. Remember we will not in anyway allow __call to handle
> inheritance.
> 
> regards
> marcus

Gotcha.

So to be clear, here's what the language has and behaves now:
1. __call allows for method overloading
2. interfaces, method_exists, and Reflection API tells if a physical
method exists - including __call method itself
3. is_callable tells if a method is callable (always true if __call
is implemented)
4. Calls to a non-existent method on classes w/ no __call overloading
results in a fatal error
5. Calls to a non-existent method on classes w/ __call overloading
succeeds, but result is undefined.

And how to use it:
1. Determining if a physical method exists is easy through interfaces,
method_exists, reflection APIs
2. Implementations of __call may do what they like with the invocations
such as ignore silently, trigger an error, throw an exception or
implement some other kind of custom protocol
3. To determine if a class implementing __call will respond to a method
invocation you must call it, regardless of side-effects, and must know
the protocol used by the class you're calling

I understand if the original intention was to use __call this way, and
that the language is not planned to change.  I suggest such a change for
the benefit of the language and its users by providing consistency.

It seems this behavior of method overloading introduces an inconsistency
in the language that breaks the ease-of-use mantra of PHP.  Why should a
class who uses method overloading behave differently than a class that
does not?

5.1 added the __isset and __unset methods for allowing property
overloading to behave consistently with regular properties, allowing
both classes that do and do not implement property overloading to behave
the same.  It seems appropriate that the method overloading behave
similarly.  An everyday end-user of the language should not need to know
if he's invoking or looking to invoke an overloaded method or not.

Regards,
Andrew

-- 
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

---

## #21383 — Andi Gutmans — 2006-01-04T00:41:44+00:00

URL: https://externals.io/message/21374#21383 · In reply to: #21381

Right but you can do it in user-land. If you're writing __call() you 
could add an additional method to see if it's mapped. I don't think 
it's quite as common as isset().



At 04:05 PM 1/3/2006, Marcus Boerger wrote:
>Hello Andi,
>
>   the point is probably that there is no way in determinig whether a
>certain function is supposed to work prior to calling it.
>
>regards
>marcus
>
>Wednesday, January 4, 2006, 12:45:23 AM, you wrote:
>
> > […]
>
> > […]
>
>
>
>
>Best regards,
>  Marcus

---

## #21384 — Marcus Boerger — 2006-01-04T01:23:51+00:00

URL: https://externals.io/message/21374#21384 · In reply to: #21382

Hello Andrew,

  you got everything correct and i see your point, so you may want to open a
feature request under bugs.php.net.

marcus

Wednesday, January 4, 2006, 1:37:26 AM, you wrote:

> Hi Marcus,

> 
> > […]

> Gotcha.

> So to be clear, here's what the language has and behaves now:
> 1. __call allows for method overloading
> 2. interfaces, method_exists, and Reflection API tells if a physical
> method exists - including __call method itself
> 3. is_callable tells if a method is callable (always true if __call
> is implemented)
> 4. Calls to a non-existent method on classes w/ no __call overloading
> results in a fatal error
> 5. Calls to a non-existent method on classes w/ __call overloading
> succeeds, but result is undefined.

> And how to use it:
> 1. Determining if a physical method exists is easy through interfaces,
> method_exists, reflection APIs
> 2. Implementations of __call may do what they like with the invocations
> such as ignore silently, trigger an error, throw an exception or
> implement some other kind of custom protocol
> 3. To determine if a class implementing __call will respond to a method
> invocation you must call it, regardless of side-effects, and must know
> the protocol used by the class you're calling

> I understand if the original intention was to use __call this way, and
> that the language is not planned to change.  I suggest such a change for
> the benefit of the language and its users by providing consistency.

> It seems this behavior of method overloading introduces an inconsistency
> in the language that breaks the ease-of-use mantra of PHP.  Why should a
> class who uses method overloading behave differently than a class that
> does not?

> 5.1 added the __isset and __unset methods for allowing property
> overloading to behave consistently with regular properties, allowing
> both classes that do and do not implement property overloading to behave
> the same.  It seems appropriate that the method overloading behave
> similarly.  An everyday end-user of the language should not need to know
> if he's invoking or looking to invoke an overloaded method or not.

> Regards,
> Andrew

> -- 
> Andrew Yochum
> Plexpod
> andrew@plexpod.com
> 718-360-0879




Best regards,
 Marcus

---

## #21385 — Marcus Boerger — 2006-01-04T01:24:50+00:00

URL: https://externals.io/message/21374#21385 · In reply to: #21383

Hello Andi,

  we didn't saw any necessaty for __isset either.

marcus

Wednesday, January 4, 2006, 1:41:44 AM, you wrote:

> Right but you can do it in user-land. If you're writing __call() you 
> could add an additional method to see if it's mapped. I don't think 
> it's quite as common as isset().



> At 04:05 PM 1/3/2006, Marcus Boerger wrote:
> > […]

---

## #21386 — Andi Gutmans — 2006-01-04T01:29:11+00:00

URL: https://externals.io/message/21374#21386 · In reply to: #21385

I think it's different especially as it's complementary to unset() 
but I don't intend to get into an argument about it.
In any case, the tools for Andrew to resolve this programmatically on 
the PHP level exist even if the syntax isn't 100% of what he'd like it to be.

Over and out.

Andi

At 05:24 PM 1/3/2006, Marcus Boerger wrote:
>Hello Andi,
>
>   we didn't saw any necessaty for __isset either.
>
>marcus
>
>Wednesday, January 4, 2006, 1:41:44 AM, you wrote:
>
> > […]
>
>
>
> > […]
> trivial to do so.
> > […]

---

## #21388 — Andrew Yochum — 2006-01-04T01:37:57+00:00

URL: https://externals.io/message/21374#21388 · In reply to: #21378

> I see your point with detection by something like __is_callable(), although 
> I can't personally think of a place where I'd use it.

Consider a situation where a proxy/mediator/broker class implementing
__call proxyies method calls to other classes (possibly of 3rd party
origins), which themselves may or may not implement __call.  You'd like
the broker itself to have a consistent behavior for the sake of its
users and good clean code.  That's very difficult if the classes it's
proxying for can't agree on a consistent behavior.  The result might be
lots of special cases in various levels of code, not to mention the
possibility of a fatal error if any of the __call implementations try to
behave like the language does.  A change in the language could eliminate
the ambiguity.

Regards,
Andrew

-- 
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

---

## #21389 — Andrew Yochum — 2006-01-04T01:59:36+00:00

URL: https://externals.io/message/21374#21389 · In reply to: #21386

> I think it's different especially as it's complementary to unset() 
> but I don't intend to get into an argument about it.

I see your point there about isset and unset being a matched pair.  From
my perspective, call is similar to unset.  It is implemented as a "black
box" and has no complementary introspection method like isset to figure
out how the black box works - at least as part of the language.  unset
has side-effects by nature of its intention, as might use of call.
isset is intended to be a no side-effect poke at a property, but no
such complement exists for call.

> In any case, the tools for Andrew to resolve this programmatically on 
> the PHP level exist even if the syntax isn't 100% of what he'd like it to 
> be.

100% agreed and I have done so.

I've brought it up for the community's benefit, as I think it is an area
that has room for some improvement.  I can see it becoming an issue as
the frameworks and libraries for 5 continues to build and are
integrated.  I don't want to argue either - just trying to have
productive discussion.

Regards,
Andrew

-- 
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

---

## #21390 — Mike Naberezny — 2006-01-04T02:05:31+00:00

URL: https://externals.io/message/21374#21390 · In reply to: #21388

Andrew Yochum wrote:
> Consider a situation where a proxy/mediator/broker class implementing
> __call proxyies method calls to other classes (possibly of 3rd party
> origins), which themselves may or may not implement __call.  You'd like
> the broker itself to have a consistent behavior for the sake of its
> users and good clean code.  That's very difficult if the classes it's
> proxying for can't agree on a consistent behavior.  The result might be
> lots of special cases in various levels of code, not to mention the
> possibility of a fatal error if any of the __call implementations try to
> behave like the language does.  A change in the language could eliminate
> the ambiguity.

Hi Andrew,

I understand your scenario and I agree but I think that this would be better 
done in userland by implementing an interface.

Remember that all of the magic methods do not need to be declared, i.e. you 
will always be able to declare __call() without __iscallable().  This is quite 
a contrast to implementing an interface such as ArrayAccess, where offsetSet() 
and offsetExists() must always be defined in your class.

The interface enforces a public contract and the behavior of the object is 
therefore always guaranteed, which is what you are seeking.  In the case of 
__iscallable(), its behavior can never have such a guarantee because 
programmers may not declare it, so the inconsistency will always exist.

With that being said, I don't think __iscallable() is a bad idea.  My only 
reservation with adding it is that it's probably going to become even more 
confusing for users to remember which magic methods are available in which PHP 
versions.

Best,
Mike

---

## #21391 — Andrew Yochum — 2006-01-04T02:14:18+00:00

URL: https://externals.io/message/21374#21391 · In reply to: #21384

> Hello Andrew,
> 
>   you got everything correct and i see your point, so you may want to open a
> feature request under bugs.php.net.
> 
> marcus

Thanks. Will do.

Regards,
Andrew

-- 
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

---

## #21392 — Andrew Yochum — 2006-01-04T02:54:54+00:00

URL: https://externals.io/message/21374#21392 · In reply to: #21390

Hi Mike,


> Hi Andrew,
> 
> I understand your scenario and I agree but I think that this would be 
> better done in userland by implementing an interface.
> 
> Remember that all of the magic methods do not need to be declared, i.e. you 
> will always be able to declare __call() without __iscallable().  This is 
> quite a contrast to implementing an interface such as ArrayAccess, where 
> offsetSet() and offsetExists() must always be defined in your class.
> 
> The interface enforces a public contract and the behavior of the object is 
> therefore always guaranteed, which is what you are seeking.  In the case of 
> __iscallable(), its behavior can never have such a guarantee because 
> programmers may not declare it, so the inconsistency will always exist.
> 
> With that being said, I don't think __iscallable() is a bad idea.  My only 
> reservation with adding it is that it's probably going to become even more 
> confusing for users to remember which magic methods are available in which 
> PHP versions.
> 
> Best,
> Mike

I whole-heartedly agree with the interface implementation vs. magic
methods.  My current implementation uses interfaces.  It seems that
most, if not all, magic method-like behavior might be interfaces down
the road.  Just curious...what is the party line on that subject?

And does such an interface deserve to be part of SPL?

Regards,
Andrew

-- 
Andrew Yochum
Plexpod
andrew@plexpod.com
718-360-0879

---

## #21394 — Sebastian Bergmann — 2006-01-04T07:13:24+00:00

URL: https://externals.io/message/21374#21394 · In reply to: #21380

Mike Naberezny schrieb:
> If one is determined enough, at least visibility can be faked by
> exception trace introspection.

 You do not need exceptions for this, just use `debug_backtrace()`.

-- 
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

---

## #21395 — Stanislav Malyshev — 2006-01-04T09:16:53+00:00

URL: https://externals.io/message/21374#21395 · In reply to: #21381

MB>>  the point is probably that there is no way in determinig whether a 
MB>>certain function is supposed to work prior to calling it.

This is the case for all functions. For example, if you call mysql_query, 
you have no way of knowing if it would succeed prior to calling it. So 
__call is not much different - you know it will call __call but you don't 
know if the call would succeed.

-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

---

## #21396 — Derick Rethans — 2006-01-04T09:19:22+00:00

URL: https://externals.io/message/21374#21396 · In reply to: #21395

> MB>>  the point is probably that there is no way in determinig whether a 
> MB>>certain function is supposed to work prior to calling it.
> 
> This is the case for all functions. For example, if you call mysql_query, 
> you have no way of knowing if it would succeed prior to calling it. So 
> __call is not much different - you know it will call __call but you don't 
> know if the call would succeed.

That is not fully true, as you can use `function_exists()` on mysql_query, 
where there is no such possibility for methods that are overloaded with 
__call().

Derick

---

## #21397 — Stanislav Malyshev — 2006-01-04T09:24:20+00:00

URL: https://externals.io/message/21374#21397 · In reply to: #21396

DR>>That is not fully true, as you can use `function_exists()` on 
DR>>mysql_query, where there is no such possibility for methods that are 
DR>>overloaded with __call().

That's correct, of course - this is the whole point of __call - it makes 
_any_ function exist. Now, calling these functions may succeed or fail - 
just as calling any other functions may succeed or fail.

-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

---

## #21402 — Marcus Boerger — 2006-01-04T11:20:23+00:00

URL: https://externals.io/message/21374#21402 · In reply to: #21397

Hello Stanislav,

  but that is a way of having __call that obviously doesn't fit the real
world. In a real world application i only implement a few things with call
and dislike having all the others implemented automatically also. And the
i have to care about error generation while the engine could help me a lot
so that my error messages look and behave just like they would if there
is no __call. But that would indeed require some __exists() or
__implemented() support().

marcus

Wednesday, January 4, 2006, 10:24:20 AM, you wrote:

DR>>>That is not fully true, as you can use `function_exists()` on 
DR>>>mysql_query, where there is no such possibility for methods that are 
DR>>>overloaded with __call().

> That's correct, of course - this is the whole point of __call - it makes 
> _any_ function exist. Now, calling these functions may succeed or fail - 
> just as calling any other functions may succeed or fail.

> -- 
> Stanislav Malyshev, Zend Products Engineer
> stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115




Best regards,
 Marcus

---

## #21403 — Stanislav Malyshev — 2006-01-04T11:32:29+00:00

URL: https://externals.io/message/21374#21403 · In reply to: #21402

MB>>  but that is a way of having __call that obviously doesn't fit the real
MB>>world. In a real world application i only implement a few things with call
MB>>and dislike having all the others implemented automatically also. And the
MB>>i have to care about error generation while the engine could help me a lot
MB>>so that my error messages look and behave just like they would if there
MB>>is no __call. But that would indeed require some __exists() or
MB>>__implemented() support().

Nothing prevents you from having __implemented or __whateveryoulike. 
However, I don't see how engine could know beforehand if your __call would 
succeed or not, so __implemented has no relation whatsoever to __call, 
unless you make this relation in your code - and engine can't know you 
did.

-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

---

## #21404 — Peter Brodersen — 2006-01-04T11:33:32+00:00

URL: https://externals.io/message/21374#21404 · In reply to: #21396

On Wed, 4 Jan 2006 10:19:22 +0100 (CET), in php.internals
derick@php.net (Derick Rethans) wrote:


>That is not fully true, as you can use `function_exists()` on mysql_query, 
>where there is no such possibility for methods that are overloaded with 
>__call().

.. with some exceptions though (function names might exist but still
unusable), as mentioned in the documentation.

-- 
- Peter Brodersen

---

## #21405 — Lukas Smith — 2006-01-04T11:50:56+00:00

URL: https://externals.io/message/21374#21405 · In reply to: #21403

Stanislav Malyshev wrote:
> MB>>  but that is a way of having __call that obviously doesn't fit the real
> MB>>world. In a real world application i only implement a few things with call
> MB>>and dislike having all the others implemented automatically also. And the
> MB>>i have to care about error generation while the engine could help me a lot
> MB>>so that my error messages look and behave just like they would if there
> MB>>is no __call. But that would indeed require some __exists() or
> MB>>__implemented() support().
> 
> Nothing prevents you from having __implemented or __whateveryoulike. 
> However, I don't see how engine could know beforehand if your __call would 
> succeed or not, so __implemented has no relation whatsoever to __call, 
> unless you make this relation in your code - and engine can't know you 
> did.

I think its obvious that you can implement things in userland or inside 
the engine. The main advantage of doing it inside the engine is that it 
then becomes the standard way of doing things, where as with userland 
its likely that several competing "standards" will emerge. Not because 
of real advantages, but just because of lack of a central standard.

However maybe its sufficient to just have an interface that defines the 
signature of such a "check if method is implemented by __call()" method 
along with a bit of text. That should imho be a sufficient approach. 
Without the need of adding yet another magic method to the engine itself.

regards,
Lukas

---

Next page: https://externals.io/message/21374.md?page=2