Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21392 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31050 invoked by uid 1010); 4 Jan 2006 02:58:43 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 31035 invoked from network); 4 Jan 2006 02:58:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jan 2006 02:58:43 -0000 X-Host-Fingerprint: 147.202.47.146 cruiser.plexpod.net Linux 2.5 (sometimes 2.4) (4) Received: from ([147.202.47.146:48970] helo=cruiser.plexpod.net) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 6C/93-34518-3E93BB34 for ; Tue, 03 Jan 2006 21:58:43 -0500 Received: from dsl254-067-175.nyc1.dsl.speakeasy.net ([216.254.67.175] helo=desario.homelinux.net) by cruiser.plexpod.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1Etyr3-0000ET-Oe; Tue, 03 Jan 2006 21:58:25 -0500 Received: by desario.homelinux.net (sSMTP sendmail emulation); Tue, 3 Jan 2006 21:54:54 -0500 Date: Tue, 3 Jan 2006 21:54:54 -0500 To: Mike Naberezny Cc: internals@lists.php.net Message-ID: <20060104025454.GL26280@desario.homelinux.net> References: <20060103205728.GF26280@desario.homelinux.net> <1852411085.20060103220656@marcus-boerger.de> <20060103213332.GG26280@desario.homelinux.net> <43BB0C61.1070806@zend.com> <20060104013756.GI26280@desario.homelinux.net> <43BB2D6B.7070108@zend.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43BB2D6B.7070108@zend.com> User-Agent: Mutt/1.5.11 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cruiser.plexpod.net X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - plexpod.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [PHP-DEV] __call overload detection From: andrew@plexpod.com (Andrew Yochum) Hi Mike, On Tue, Jan 03, 2006 at 06:05:31PM -0800, Mike Naberezny wrote: > 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