# __call interceptor and static methods - Thread: https://externals.io/message/13765 - Original archive: https://news-web.php.net/php.internals/13765 - Started by Timm Friebe on 2004-11-07T16:26:12+00:00 - Messages: 8 - 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 --- ## #13765 — Timm Friebe — 2004-11-07T16:26:12+00:00 URL: https://externals.io/message/13765#13765 Hi, is there any reason why __call shouldn't be invoked for static method calls? Reproduce --------- php5 -r 'class A { function __call($name, $args) { var_dump($name, $args); } } A::foo();' Actual result ------------- Fatal error: Call to undefined method A::foo() in Command line code on line 1 Expected result --------------- string(3) "foo" array(0) { } - Timm --- ## #13766 — Sebastian Bergmann — 2004-11-07T17:28:18+00:00 URL: https://externals.io/message/13765#13766 · In reply to: #13765 Timm Friebe wrote: > is there any reason why __call shouldn't be invoked for static method > calls? None that I can think of. If it is doable it should be supported. -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #13774 — Andi Gutmans — 2004-11-07T23:26:29+00:00 URL: https://externals.io/message/13765#13774 · In reply to: #13765 In most cases method overloading is used for objects and not for classes (for example, initiating a SOAP object and then calling methods on it.). It doesn't make sense to mix these two things because it would lead to confusion what context the method was called in. You would either need another call back or pass a flag to __call() and in my opinion just doesn't seem to be worth it. Andi At 05:26 PM 11/7/2004 +0100, Timm Friebe wrote: >Hi, >is there any reason why __call shouldn't be invoked for static method >calls? > >Reproduce >--------- >php5 -r 'class A { function __call($name, $args) { var_dump($name, >$args); } } A::foo();' > >Actual result >------------- >Fatal error: Call to undefined method A::foo() in Command line code on >line 1 > >Expected result >--------------- >string(3) "foo" >array(0) { >} > >- Timm --- ## #13782 — Marcus Boerger — 2004-11-08T10:18:33+00:00 URL: https://externals.io/message/13765#13782 · In reply to: #13765 Hello Timm, you won't be able to tell from inside __call() whether a static or non static method was meant. The same holds for __get() and __set(). Also if we start using such code we'd need a class constructor. Thus this dicussion is leading to the following set of new magics: __static_get __static_set __static_call __static_construct regards marcus p.s.: something usefull when it comes to aspect oriented programming Sunday, November 7, 2004, 5:26:12 PM, you wrote: > Hi, > is there any reason why __call shouldn't be invoked for static method > calls? > Reproduce > --------- > php5 -r 'class A { function __call($name, $args) { var_dump($name, > $args); } } A::foo();' > Actual result > ------------- > Fatal error: Call to undefined method A::foo() in Command line code on > line 1 > Expected result > --------------- > string(3) "foo" > array(0) { > } > - Timm -- Best regards, Marcus mailto:helly@php.net --- ## #13783 — Stanislav Malyshev — 2004-11-08T10:29:13+00:00 URL: https://externals.io/message/13765#13783 · In reply to: #13782 MB>> you won't be able to tell from inside __call() whether a static or MB>> non static method was meant. Technically, it's not a big problem IMO - there could be an argument added or some other solution, like presence of $this. MB>>non static method was meant. The same holds for __get() and __set(). MB>>Also if we start using such code we'd need a class constructor. Thus MB>>this dicussion is leading to the following set of new magics: MB>> MB>>__static_get MB>>__static_set MB>>__static_call MB>>__static_construct What do you mean by __static_construct? When do you expect it to be called? And, BTW - if you need to override method calls, etc. for a global object, why not to use singletons? -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115 --- ## #13784 — Marcus Boerger — 2004-11-08T10:45:24+00:00 URL: https://externals.io/message/13765#13784 · In reply to: #13783 Hello Stanislav, Monday, November 8, 2004, 11:29:13 AM, you wrote: MB>>> you won't be able to tell from inside __call() whether a static or MB>>> non static method was meant. > Technically, it's not a big problem IMO - there could be an argument added > or some other solution, like presence of $this. Adding an argument would be a major BC but sure is_null($this) would work, only it would be another big slowdown. MB>>>non static method was meant. The same holds for __get() and __set(). MB>>>Also if we start using such code we'd need a class constructor. Thus MB>>>this dicussion is leading to the following set of new magics: MB>>> MB>>>__static_get MB>>>__static_set MB>>>__static_call MB>>>__static_construct > What do you mean by __static_construct? When do you expect it to be > called? And, BTW - if you need to override method calls, etc. for a > global object, why not to use singletons? I didn't say it is necessary :-) __static_construct would be called the first time the class is going to be used. Best regards, Marcus mailto:helly@php.net --- ## #13785 — Stanislav Malyshev — 2004-11-08T10:57:37+00:00 URL: https://externals.io/message/13765#13785 · In reply to: #13784 MB>>Adding an argument would be a major BC but sure is_null($this) would work, MB>>only it would be another big slowdown. I don't think 2-3 additional opcodes are a "big" slowdown - if you are using non-default ctors and accessors anyway, you probably are doing something order of magnitude bigger there, not to mention PHP function call is costly by itself. As for BC - I think it can be made so it would accept old code too, and some set of rules could be made about when to call what - e.g., basing on number of arguments. If, of course, the whole thing is needed anyway :) MB>>__static_construct would be called the first time the class is going to be MB>>used. The idea doen't seem appealing to me... I wonder why one would need such tricks and why one won't use more civilized way of doing things - like appropriate patterns which don't have to require such magic. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115 --- ## #13800 — Timm Friebe — 2004-11-10T00:55:13+00:00 URL: https://externals.io/message/13765#13800 · In reply to: #13782 > Hello Timm, > > you won't be able to tell from inside __call() whether a static or > non static method was meant. isset($this) does work fine. > The same holds for __get() and __set(). > Also if we start using such code we'd need a class constructor. Why? > Thus this dicussion is leading to the following set of new magics: [...] Instead of this: How about an extra (third) parameter $context to __call() which holds either object $this or string $classname. The signature would then be: mixed __call(string $name, array $args [, mixed $context]); Checking whether __call() was statically invoked could either be performed via code such as: is_object($context) ? 'in context of '.get_class($context) : 'statically in class '.$context On Mon, 2004-11-08 at 00:26, Andi Gutmans wrote: > In most cases method overloading is used for objects and not for classes > (for example, initiating a SOAP object and then calling methods on it.). > It doesn't make sense to mix these two things because it would lead to > confusion what context the method was called in. You would either need > another call back or pass a flag to __call() and in my opinion just doesn't > seem to be worth it. I think an extra flag wouldn't really hurt. No BC issue btw (mentioned in another mail), extra parameters are always ignored. Just like the `set_error_handler()` callback which you can add the array $context parameter to. - Timm