Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:20488
Return-Path: <oliver.graetz@arcor.de>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 27936 invoked by uid 1010); 26 Nov 2005 05:00:23 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 27920 invoked from network); 26 Nov 2005 05:00:23 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 26 Nov 2005 05:00:23 -0000
X-Host-Fingerprint: 84.60.44.127 dslb-084-060-044-127.pools.arcor-ip.net  
Received: from ([84.60.44.127:24261] helo=localhost.localdomain)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id 21/68-56276-6EBE7834 for <internals@lists.php.net>; Sat, 26 Nov 2005 00:00:22 -0500
Message-ID: <21.68.56276.6EBE7834@pb1.pair.com>
To: internals@lists.php.net
Date: Sat, 26 Nov 2005 06:00:18 +0100
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
References: <7.0.0.16.2.20051124161240.0573e640@zend.com>	<pan.2005.11.25.07.40.45.515129@php.net> <90.0E.56276.6D207834@pb1.pair.com>	<200511251419.56809.pookey@pookey.co.uk> <57.B8.56276.65B27834@pb1.pair.com>	<73998811.20051125204046@marcus-boerger.de> <438782C6.80008@gmail.com>	<43878626.5060300@lerdorf.com> <DD.1D.56276.6B787834@pb1.pair.com> <512771162.20051125225926@marcus-boerger.de> <6B.D6.56276.154E7834@pb1.pair.com> <4387E67E.5030008@gmail.com>
In-Reply-To: <4387E67E.5030008@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Posted-By: 84.60.44.127
Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)
From: oliver.graetz@arcor.de (=?ISO-8859-1?Q?Oliver_Gr=E4tz?=)

Jessie Hernandez schrieb:
>>> that's only one case,go with consts. now try
>>>$x = $y ? foo:bar:baz:stupid;
>>[... my two cents...] 

> Thank you!!! This is exactly what happens with my patch now in this 
> case, one constant named "foo:bar:baz:stupid" is parsed and a syntax 
> error is produced because of a missing colon and third argument. So, for 
> this to be interpreted right, a space must be added after "foo:bar" at 
> the very least (alternatively, use parentheses). This is simply a side 
> effect of the implementation, but it can actually be considered a 
> _feature_, since it promotes code clarity in this instance (again, this 
> only happens and is only required in this ONE instance).

Well, then again: There's still the difference between : and :: .
(intended whitespace inserted in front of the period *g*)

So if one only allows simple namespaces (no nesting), then one can see
that this need to be two namespace constants BUT one has to read the
whole line:

- one colon means simple constants
- three colons: two namespaces constants
- two colons: ERROR, undefined

My opinion: Throw a parser error for missing third argument and enforce
using parentheses. Not allowing constants in namespaces would mean that
the current PHP core could not be put inside a "PHP" namespace because
(guess what) it contains global constants.

OLLi

PS: How about a unicode symbol (egypt god Ra) as namespace operator.
PHP6 will be all about unicode => Yeah, gazillions of new operator
symbols. Or register a "PHP namespace separator symbol" that looks like
the PHP logo. Just kidding...