Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41264
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Sat, 18 Oct 2008 22:33:14 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1061064720.20081018223314@marcus-boerger.de>
To: Greg Beaver <greg@chiaraquartet.net>
CC: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <48F653FF.5010106@chiaraquartet.net>
References: <48F653FF.5010106@chiaraquartet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] my last attempt at sanity with namespaces
From: helly@php.net (Marcus Boerger)

Hello Greg,

  Many thanks for wirting a nice proposal. Now, I consider #2 and #4 as
no options, just as most everyone else. Regarding #3, I see it
contradicting our KISS approach. You can actually write code where an
Identifier in two scripts that share the same includes mean something
completely different. Please not. Your #1 is actually my number 1 and I
said so about 5 years ago in the first napesace implementation. And I
said so over a year ago. I like #1 because it is easier, conflict free
by design and does not have any issue with __autoload or whatever.

In your RFC you write under con 2, that there are issues with missing
triple colons. However for the most cases the users are safe. Especially
in code like you are showing the compiler can tell that it must be wrong.
That is you can only have on double colon on the right and no other one
left of that. And if this is still too problematic we could even make it
a quad colon. That should be easy enough to read.

Besides the above I think our users want 'use' in their if clauses. And
we have to consider that. Technically we can easily allow use in the main
block outside functions. But that will interfere with compiler caches. So
as practical that might be, I think we should not really do it. And if at
some later point in time we think it is absolutely necessary we can at it
in PHP 10 or whatever.

Next I do not want any special treatment for internal classes at all!

If the user wants to hide the exception class then he has to derive the
original one that he finds in the main namespace:

<?php
namespace ShootInTheFoot;
use my_stupid_exception as Exception;
throw Exception;

Well the user wanted to and did:

<?php
namespace ShootInTheFoot;
class Exception extends :::Exception { }


Having use inside if gives us:

<?php
namespace MyApp;
if ($_GLOBALS['logging']) {
  use MyLoggingException;
} else {
  use :::Exception as Exception;
}
throw Exception;   // Which loggs if I want to

However we already have if for includes. So the question is whether we
want to increase the mess (from a compiler caches point of view) or not.


just my $0.02

marcus

Wednesday, October 15, 2008, 10:35:11 PM, you wrote:

> Hi,

> http://wiki.php.net/rfc/namespaceissues

> Read it and discuss.  Let's be clear people: the technical problems in
> namespaces are limited and solvable.  The problems in the political
> environment surrounding them may not be.  Wouldn't politics be a
> stupid-ass reason to remove namespaces?

> Greg




Best regards,
 Marcus