Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:13785 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23777 invoked by uid 1010); 8 Nov 2004 10:57:40 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 23524 invoked from network); 8 Nov 2004 10:57:38 -0000 Received: from unknown (HELO mail.zend.com) (80.74.107.235) by pb1.pair.com with SMTP; 8 Nov 2004 10:57:38 -0000 Received: (qmail 21791 invoked from network); 8 Nov 2004 10:57:37 -0000 Received: from shire.zend.office (10.1.2.160) by int.zend.com with SMTP; 8 Nov 2004 10:57:37 -0000 Date: Mon, 8 Nov 2004 12:57:37 +0200 (IST) X-X-Sender: frodo@shire.zend.office To: Marcus Boerger cc: internals@lists.php.net In-Reply-To: <129726745.20041108114524@marcus-boerger.de> Message-ID: References: <1099844772.320.6.camel@localhost> <15410470363.20041108111833@marcus-boerger.de> <129726745.20041108114524@marcus-boerger.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] __call interceptor and static methods From: stas@zend.com (Stanislav Malyshev) 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