Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40588
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.24 cause and error)
To: internals@lists.php.net
Date: Sat, 20 Sep 2008 20:00:38 -0500
User-Agent: KMail/1.9.9
References: <48D47532.8080102@chiaraquartet.net> <e666c3890809200924t28f1c585kad77729dd608c5ad@mail.gmail.com> <10845a340809201643q59e27211i471e09241f7253b1@mail.gmail.com>
In-Reply-To: <10845a340809201643q59e27211i471e09241f7253b1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200809202000.38870.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant
From: larry@garfieldtech.com (Larry Garfield)

On Saturday 20 September 2008 6:43:41 pm Richard Quadling wrote:

> >> 5) a simply syntax change to namespaces, introducing a new concept:
> >> namespace element.
> >>
> >> A namespace element is a class, function or constant defined within a
> >> namespace declaration:
> >>
> >> <?php
> >> namespace foo;
> >> class bar {} // class element bar in namespace foo
> >> function bar(){} // function element bar in namespace foo
> >> const bar=1; // const element bar in namespace foo
> >> ?>
> >>
> >> This is similar to class elements:
> >>
> >> <?php
> >> class foo {
> >> function bar(){} // method element bar in class foo
> >> const bar=1; // constant element bar in class foo
> >> public $bar=1; // variable element bar in class foo
> >> }
> >> ?>
> >>
> >> Currently, this code:
> >>
> >> <?php
> >> namespace foo::bar;
> >> class buh{}
> >> ?>
> >>
> >> creates a class named "foo::bar::buh", essentially joining the namespace
> >> "foo::bar" and its class element "buh" with the separator "::".  This
> >> turns out to be the root of the problem with the conflicts between class
> >> elements and namespace elements.  The last patch introduces a new
> >> namespace element operator to delineate the boundary between namespace
> >> name and element name. For the patch, I recycled T_OBJECT_OPERATOR (->).
> >>
> >> current way:
> >> <?php
> >> foo::bar->test(); // namespace foo::bar, call to function element test()
> >> foo->bar::test(); // namespace foo, call to static method element test()
> >> in class element bar
> >> foo->myconst; // namespace foo constant myconst
> >> foo::myconst; // class foo constant myconst
> >> ?>
> >>
> >> The patch is at:
> >>
> >> http://pear.php.net/~greg/ns.element.patch.txt
> >>
> >> This is the most extensive change.  The patch preserves :: as global
> >> element accessor (::strlen() calls strlen internal function, for
> >> instance).  I'm happy to answer any other questions.
> >>
> >> So, these are the choices.  I suggest we all take a rational look at the
> >> options, and understand the consequences of each, and make the best
> >> choice possible.
> >>
> >> Thanks,
> >> Greg
> >
> > Good work, but I (and I'm probably not alone) can't really keep up
> > with all those namespace threads and proposals for changes and
> > resolution fixes and this and that,so :
> >
> > Please use our nice RFC system!
> >
> > Regards
> >
> > --
> > Etienne Kneuss
> > http://www.colder.ch
> >
> > Men never do evil so completely and cheerfully as
> > when they do it from a religious conviction.
> > -- Pascal
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> How feasible would it be to use # as the namespace separator. I know #
> is used for comments, but with /* */ and // that all seems covered.
>
> namespace#function() vs class::static()
>
> Seems like a winner. Just a whole ton of BC though for those using #
> for comments.

I agree that #5 seems like the best solution.  The problem is caused by the 
double meaning of ::.  All of the other solutions feel like bandaids.  

Of course, the problem then is finding a symbol that is not already used.  I 
don't think reusing -> is any wiser than reusing ::.  # would be great if it 
wasn't already in use, but that sort of change is really not appropriate for 
5.3.  What other symbols are available or could be created?  (::: has been 
suggested and would give the opportunity to introduce more Hebrew into the 
language parser...)

-- 
Larry Garfield
larry@garfieldtech.com