Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34229
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.146.180 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=GjDqHw+9+D19ktGKdBmxNPOZbad6Yp3KLf7wwg8UsUnDHyk5jpTICaUPd382SJXZp1DM5zFYn/n8hMX2WswuqFXsqo1tktm/QYaFaIGsyG70ZM2ZfKf0zISO/CnCN1M+eAm5uyFYYp/XKrsbUWHc9vG+Pi48jPfwOoUT1QlbtDM=
Message-ID: <52dbac0f0712222014t75cef9fcnb96c0dd61b810a6c@mail.gmail.com>
Date: Sun, 23 Dec 2007 01:14:47 -0300
To: "Greg Beaver" <cellog@php.net>
Cc: "PHP Developers Mailing List" <internals@lists.php.net>
In-Reply-To: <476B3C57.6070102@php.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_3906_9501301.1198383287453"
References: <52dbac0f0712201536s7fab82a7y2a7111ca5a11711e@mail.gmail.com>
	 <476B3C57.6070102@php.net>
Subject: Re: Maybe a problem? undetected name clash makes static method unaccessible through outside static reference
From: malterisio777@gmail.com ("Martin Alterisio")

------=_Part_3906_9501301.1198383287453
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

2007/12/21, Greg Beaver <cellog@php.net>:
>
> Martin Alterisio wrote:
> > Consider the following code:
> >
> > foo.php:
> > <?php
> > class test {
> >   public static function foo() { echo "I'm foo in class test\n"; }
> >   public static function foo2() { self::foo(); }
> > }
> > ?>
> >
> > foo2.php:
> > <?php
> > namespace test;
> > function foo() { echo "I'm foo in namespace test\n"; }
> > ?>
> >
> > test.php:
> > <?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
>

Sorry, I was busy with something else and forget about this thread for a
while.

I've tried ::test::foo() but it calls the namespaced function too.

I'm trying two approaches to solve this issue:

1) raise an error on function call if the ambiguity is found

2) raise an error on function declaration if the ambiguity is found

With (1) the problem I have is: how to provide a way to solve the ambiguity?
ie, how can one say if he's referring to the class method or the namespaced
function?

With (2) one element cannot exist if the other exist. This is a more
sensible approach if you're in the "there cannot be two elements which are
referred with the same name" way of thinking. But considering that php
allows classes and functions to share names... Anyway, the problem with this
approach is that the extra checks needed must be done at runtime...

Bottom line, if anyone has more ideas... I'll be more than grateful to hear
them.

Best Regards,

Martin Alterisio.

------=_Part_3906_9501301.1198383287453--