Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26601
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 64.233.166.176 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=DkCfRDahNcQjghn+GN1ndAhyljeAxRbgp/83br3+dQPwEcDytpdzDoe/6m2urIDZcplEupeDLno55bLcxz3MOZBOeysTo+7ZGjMiIZz/4Qg0Or67iBOu6vfudOS1t7WKPInST3s/+th0SgA4iOxgZXZe1jUaODYJw2VVxMH4JdI=
Message-ID: <10845a340611150039o2c51795dt5f78877ce9678d65@mail.gmail.com>
Date: Wed, 15 Nov 2006 08:39:48 +0000
Reply-To: RQuadling@GoogleMail.com
To: "Marcus Boerger" <helly@php.net>
Cc: "Jessie Hernandez" <jrhernandez05@gmail.com>, internals@lists.php.net
In-Reply-To: <607959001.20061114205107@marcus-boerger.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4554AE0D.4080600@caedmon.net> <99.20.32592.5ED45554@pb1.pair.com>
	 <19674119.20061111112203@marcus-boerger.de>
	 <3D.90.24000.85F66554@pb1.pair.com> <4557017A.3020804@gmail.com>
	 <95.78.60788.E6F39554@pb1.pair.com>
	 <832678080.20061114090929@marcus-boerger.de>
	 <10845a340611140036x2ad3122u7f562cfb2dca2c38@mail.gmail.com>
	 <607959001.20061114205107@marcus-boerger.de>
Subject: Re: [PHP-DEV] Re: Namespaces in PHP 6 - ++$take
From: rquadling@googlemail.com ("Richard Quadling")

Would $foo = "{mynamespace\tables_class::myconst}";

\t in "" is a tab. \m in "" is nothing but \m

Thats the sort of thing I'm worried about.

On 14/11/06, Marcus Boerger <helly@php.net> wrote:
> Hello Richard,
>
> The "#" is needed for CLI mode - thus we won't remove it. In fact we
> will not do anything that would cause BC problems. Also there is no
> escaping issue with "\". If there is than it is outside of PHP. In
> other words:
> - "\" is the only single character reachable from 'western' keyboards
> - $foo = "{mynamespace\myclass::myconst}"; // will be possible without
>   escaping
>
> Please people read the archives before posting here, we have discussed
> all this long enough.
>
> Tuesday, November 14, 2006, 9:36:10 AM, you wrote:
>
> > The only issue with using \ is the fact that this is the escape
> > character. If you are using PHP to create classes (collapsing complex
> > classes into simpler ones, implementing a fake AOP), you have to
> > remember to escape the escape. It just seems odd to re-use a symbol
> > like this. A new symbol is better. IIHMY, I would use # and remove #
> > from comments. # looks like a grid which can be thought of as a
> > compartmentalisation process; i.e. grouping things together in their
> > own little space - a perfect concept to explain namespaces. We already
> > have singleline  and block comments with // and /* ... */. Not really
> > sure of the need of #. Of course, this would be an evern bigger BC.
> > Even my own code uses #.
>
> > The triple colon (:::) is OK, but what happens during a mistype. Is
> > there a possibility that :: and ::: COULD be used interchangably (an
> > extreme example), producing working code?
>
>
>
> > On 14/11/06, Marcus Boerger <helly@php.net> wrote:
> >> Hello Jessie,
> >>
> >> Tuesday, November 14, 2006, 5:00:42 AM, you wrote:
> >>
> >> > What does everyone else think? Are functions/constants inside namespaces
> >> > really that critical?
> >>
> >> > Anyways, I just thought of a possible solution to the namespace
> >> > separator issue, and if it's doable, then the double colon (::) can even
> >> > be used and no conflicts would occur. It seems the biggest problem with
> >> > handling namespaces is determining if a symbol is a class or namespace
> >> > at compile-time. I am no expert in flex/bison, but I was thinking that a
> >> >   state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will
> >> > return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on
> >> > whether the symbol is known to be a class or namespace. The user will
> >> > add either a "using" or "import" statement before the use of the symbol,
> >> > and this will allow the parser to know what that symbol is in the
> >> > compilation phase. As an example:
> >>
> >>
> >> > // BEGIN CODE
> >> > using namespace PEAR::File;
> >> > $items = File::Find::glob( '!.*\.php$!', $dir, 'perl' );
> >> > // END CODE
> >>
> >>
> >> > The first statement will add an entry into a hashtable (used during
> >> > compilation) indicating that "PEAR", "PEAR::File", and "File" are
> >> > namespaces ("File" will be imported in the current file only). When
> >> > "File::Find::glob" is parsed, the compiler already knows that "File" is
> >> > a namespace, so "Find" must be a class inside that namespace, and "glob"
> >> > must be a static method. With this, functions and constants can easily
> >> > be added inside namespaces, as the "using" or "import" statement will
> >> > indicate to the parser which portion of the qualified name is a namespace.
> >>
> >> > Is this feasible in flex/bison? Let me know if anything needs clarification.
> >>
> >> Short: no
> >>
> >> Long: Please stop confusion here. We will get namespace innwith either ":::"
> >> or "\" depending on who is going to implement it and what otherissues that
> >> one will encounter. Later we may decide based on that implementation whether
> >> it might be possible to use a different seperator. Btw, ifI wereto implement
> >> namespacesupport today i would go with "\" as that is easier to translate to
> >> a directory/file name in an __autoload function. While yesturday people
> >> nearly convinced me (during the last conferences) that ":::" is closer to
> >> the class/member seperator "::".
> >>
> >> best regards
> >> marcus
> >>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
>
>
>
>
>
> Best regards,
>  Marcus
>
>


-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"