Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21405 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89610 invoked by uid 1010); 4 Jan 2006 11:51:19 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 89595 invoked from network); 4 Jan 2006 11:51:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jan 2006 11:51:19 -0000 X-Host-Fingerprint: 212.112.227.169 ipx11223.ipxserver.de Linux 2.5 (sometimes 2.4) (4) Received: from ([212.112.227.169:33776] helo=ipx11223.ipxserver.de) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 52/54-34518-6B6BBB34 for ; Wed, 04 Jan 2006 06:51:19 -0500 Received: from localhost (localhost [127.0.0.1]) by ipx11223.ipxserver.de (Postfix) with ESMTP id 0502ADF00C4; Wed, 4 Jan 2006 12:51:18 +0100 (CET) Received: from ipx11223.ipxserver.de ([127.0.0.1]) by localhost (ipx11223 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31658-04; Wed, 4 Jan 2006 12:51:07 +0100 (CET) Received: from [127.0.0.1] (lsmith.home.cs.tu-berlin.de [130.149.150.67]) by ipx11223.ipxserver.de (Postfix) with ESMTP id 24873DF0067; Wed, 4 Jan 2006 12:51:07 +0100 (CET) Message-ID: <43BBB6A0.1070800@php.net> Date: Wed, 04 Jan 2006 12:50:56 +0100 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stanislav Malyshev Cc: Marcus Boerger , php internals References: <20060103205728.GF26280@desario.homelinux.net> <7.0.0.16.2.20060103154506.043678e8@zend.com> <829348376.20060104010548@marcus-boerger.de> <1594973025.20060104122023@marcus-boerger.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by somedaemon at backendmedia.com Subject: Re: [PHP-DEV] __call overload detection From: lsmith@php.net (Lukas Smith) 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