Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26515
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain horde.org designates 213.83.39.131 as permitted sender)
Message-ID: <20061111135517.zqn0qes34sk4444c@neo.wg.de>
Date: Sat, 11 Nov 2006 13:55:17 +0100
To: internals@lists.php.net
References: <4554AE0D.4080600@caedmon.net>
	<D268FFAD-6916-4EDE-9511-31F5BC774318@prohost.org>
	<4554B9B5.5090305@caedmon.net>
	<DA611470-FC2C-48DE-AE6B-29EC4554A298@prohost.org>
	<4554C2C7.9070502@caedmon.net> <4554C945.3000509@velum.net>
In-Reply-To: <4554C945.3000509@velum.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=UTF-8;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs)
Subject: Re: [PHP-DEV] Namespaces in PHP 6 - ++$take
From: jan@horde.org (Jan Schneider)

Zitat von Hans Lellelid <hans@velum.net>:

>
>>> I think there is far more
>>> demand for a fast & stable PHP then for syntatic sugar features which
>>> seem extremely useful, but in the end prove to carry too much baggage.
>>>
>>
>> Nothing has been proven either way.. at least not publicly.. unless I
>> just missed it.
>>
>
> I haven't talked to a single developer a large-scale PHP tool,
> application, etc. that wouldn't switch their trunk to using namespaces
> tomorrow if they were adopted in the engine.  We [in] PHP developers who
> are building "enterprise" open-source components and frameworks really
> will use this feature -- and I think we'd all argue that we really need
> this feature.  I hope that namespaces would be more than syntactic sugar
> -- e.g. providing an import/using keyword that would declare namespace
> context -- but even if they were only "syntactic sugar" they would at
> minimum provide a naming standard for PHP packages to avoid collisions.
>
> Namespaces certainly got a lot of mention at Int'l PHP Conference (in
> form of request and, during the panel, applause from audience when
> mentioned); it was clear that this is a very anticipated PHP6 feature.
> None of us non-C developers are trying to say we think this should be
> easy, or trying to otherwise minimize the problems that have been
> presented in the past or the reasons why it hasn't been implemented so
> far, but let there be no confusion that this is a really, really
> important feature for us.

I couldn't agree more. There really wasn't an appealing reason to =20
switch to PHP5 too quickly for me, and force the users of our code to =20
do the same. There are a few reasons to switch to 5.2 probably, but =20
that's a different story.
But if there wasn't already Unicode support in PHP 6, having =20
namespaces was definitely a good reason to force our user to that =20
version.

Jan.

--=20
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/