Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:34193 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72064 invoked by uid 1010); 21 Dec 2007 04:09:02 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 72049 invoked from network); 21 Dec 2007 04:09:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Dec 2007 04:09:02 -0000 Authentication-Results: pb1.pair.com header.from=cellog@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=cellog@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 38.99.98.18 as permitted sender) X-PHP-List-Original-Sender: cellog@php.net X-Host-Fingerprint: 38.99.98.18 beast.bluga.net Linux 2.6 Received: from [38.99.98.18] ([38.99.98.18:54729] helo=mail.bluga.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C3/10-05138-D5C3B674 for ; Thu, 20 Dec 2007 23:09:02 -0500 Received: from mail.bluga.net (localhost.localdomain [127.0.0.1]) by mail.bluga.net (Postfix) with ESMTP id 20EFDC0EE47; Thu, 20 Dec 2007 21:08:59 -0700 (MST) Received: from [192.168.1.109] (ftcl002.digis.net [66.17.140.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bluga.net (Postfix) with ESMTP id AF4DDC0EE37; Thu, 20 Dec 2007 21:08:58 -0700 (MST) Message-ID: <476B3C57.6070102@php.net> Date: Thu, 20 Dec 2007 22:08:55 -0600 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Alterisio CC: PHP Developers Mailing List References: <52dbac0f0712201536s7fab82a7y2a7111ca5a11711e@mail.gmail.com> In-Reply-To: <52dbac0f0712201536s7fab82a7y2a7111ca5a11711e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Maybe a problem? undetected name clash makes static method unaccessible through outside static reference From: cellog@php.net (Greg Beaver) Martin Alterisio wrote: > Consider the following code: > > foo.php: > class test { > public static function foo() { echo "I'm foo in class test\n"; } > public static function foo2() { self::foo(); } > } > ?> > > foo2.php: > namespace test; > function foo() { echo "I'm foo in namespace test\n"; } > ?> > > test.php: > include 'foo.php'; > include 'foo2.php'; > test::foo(); // I'm foo in namespace test > use test::foo as dummy; > test::foo(); // I'm foo in namespace test > test::foo2(); // I'm foo in class test > $test = 'test'; > $test::foo(); // I'm foo in class test > call_user_func(array('test', 'foo')); // I'm foo in class test > ?> > > Please review the following observations: > > There's a name clash that goes undetected: test::foo refers to both a > namespaced function and a static method. > > Once the clash occur there's no way to refer to the static method through a > static reference, except when within the class scope where you can refer to > the method through self:: > The static method remains partially hidden by the namespaced function. Don't forget about ::test::foo() which refers to class test, method foo(). However, this is an issue, and one of the main reasons I dislike putting functions and constants in namespaces, as this ends up sort of like OO without inheritance and confuses the issue of static methods as you pointed out. However, having said that, in my experience, developers either use functions or OO, very rarely mixing the two on an extensive basis, and so name collisions become much less likely between static methods and namespaced functions. Greg