Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41145
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error)
Message-ID: <48F77416.3010106@chiaraquartet.net>
Date: Thu, 16 Oct 2008 12:04:22 -0500
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Lester Caine <lester@lsces.co.uk>, 
 PHP internals <internals@lists.php.net>
References: <48F6B3C5.9030102@chiaraquartet.net> <7f3ed2c30810152312h5391b25dke2695362c8d28d3b@mail.gmail.com> <48F6E50E.4010107@lsces.co.uk> <48F75BA3.30603@zend.com>
In-Reply-To: <48F75BA3.30603@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas'sproposal
 doesn't work
From: greg@chiaraquartet.net (Greg Beaver)

Stanislav Malyshev wrote:
> Hi!
> 
>> The problem with that statement is that if it is used to ignore the
>> other problems, then at some point it may be necessary to re-write all
>> the new namespace code simply to allow additional features to be added!
> 
> So? We rewrote pretty much every other part of PHP - engine, object
> model, filesystem, etc. - and nobody died. Suddently with this
> particular feature there's tremendous fear of commitment. But we aren't
> going anywhere by sitting and talking about "what if". We get anywhere
> only by releasing features and seeing what they do.

My point is that for this code:

<?php
Classname::Method();
?>

The proposal does not solve the name conflict.  If no one rewrites their
code to use Classname->Method(), then no one will be protected from the
ambiguity.  I am thinking of the case where a user adds a new feature to
their existing code that uses a 3rd-party library with namespaced
functions that accidentally conflict with the user's classes without
their knowledge.  As third-party libraries become easier to distribute
(which both phar and pyrus plan to do), this will become more of an issue.

Our experience with other changes forced upon existing code has shown
that user inertia is high, and we can't expect to fix things simply by
asking the users to rewrite their code unless PHP tells them to with
E_STRICT or other warnings.

Should I add this to the explanation or is it clear enough?

Greg