Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40725
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: <48DDB24A.7090705@chiaraquartet.net>
Date: Fri, 26 Sep 2008 23:10:50 -0500
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807)
MIME-Version: 1.0
To: Steph Fox <steph@php.net>
CC: Stanislav Malyshev <stas@zend.com>, 
 PHP Internals <internals@lists.php.net>
References: <9E3A4397-3595-42D8-BF73-7F7575B93772@pooteeweet.org> <003501c92037$9512fef0$3ffc1f3e@foxbox> <48DD7E3D.5060708@zend.com> <006701c92039$6245dc20$3ffc1f3e@foxbox>
In-Reply-To: <006701c92039$6245dc20$3ffc1f3e@foxbox>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] alpha3
From: greg@chiaraquartet.net (Greg Beaver)

Steph Fox wrote:
> Oh Stas, we have to fall out now!
> 
>> Imperfect solution is much better than perpetual absence of any solution.
> 
> See, I'm not sure I agree with that.
> 
> I think 'imperfect but basic solution that can be expanded on' would be
> a better approach than trying to do it all in one hit.
> 
> And I still think putting it off to PHP 6 would be a smart move. It's
> the major thing that's holding up 5.3.

Hi,

I have to respectfully disagree with both of you:

Stas: choosing an imperfect solution when a better one already exists is
just plain stupid, and isn't what you want *or* what you suggested - the
solution you, Liz, Marcus and Andi proposed is not imperfect, it is
consistent, robust and far better than the existing CVS implementation
of namespaces.  Don't sell yourself so short! :)

Steph: the limited solution proposed by Stas and company (removing
functions [and I would add constants]/fixing name resolution) *is* a
basic solution that can be expanded on.  I outlined the steps in my
reply.  It's the best solution to the problem, not an imperfect one.  A
namespace solution that works brilliantly for classes will satisfy at
least 2/3 of the users who want it.

Adding support for functions, constants and even variables is actually
quite do-able with the solution I suggested (different separator between
namespace name and function/constant/variable name) and can be added easily.

file 1:
<?php
namespace foo::bar;
class myclass {}
function myfunc()(}
var $myvar;
const myconst = 1;
?>

file 2:
<?php
include 'file1.php';
$a = new foo::bar::myclass;
foo::bar:>myfunc; // separator :> could be anything
echo foo::bar:>$myvar;
echo foo::bar:>myconst;

// all of the below would also be possible, although we may choose not
to implement things like use of a variable
use foo::bar::myclass, foo::bar:>$myvar, foo::bar:>myfunc(),
foo::bar:>myconst, foo::bar;
?>

So the question of whether we are making a mistake with Stas's
suggestion relayed from ZendCon is debunked by 2 facts:

1) the implementation is a reduced set based on the existing namespace
implementation which has been beaten up and tested thoroughly, and
because it is simpler, will be even easier to verify its veracity.
2) it can be easily extended to add support later for other components
like functions, while preserving 100% BC with the current::implementation.

There is also jvlad's suggestion to consider, but in my opinion, this
trades one conflict for another, as this code would be a fatal error:

<?php
namespace http;
class Request {}
namespace http::request; // fatal error - name conflict between class
http::request and namespace http::request
class body {}
?>

Unless we also used my suggestion of having a namespace member separator
different from scope resolution operator.

In addition, Rasmus has pointed out many times in the past that allowing
changing the namespace of external code depending on code load order
would simply break opcode caching for PHP.

Greg