Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40968
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: PHP Development <internals@lists.php.net>
Message-ID: <B1070468-6AF1-4119-9435-0E407A0E6041@pooteeweet.org>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <48EF8AA1.7080901@zend.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 14 Oct 2008 09:31:39 +0200
References: <3CF765DF-27AF-44FD-9ECF-BEBFC8A0AFCA@pooteeweet.org> <48EF8AA1.7080901@zend.com>
Subject: Re: [PHP-DEV] namespaces and alpha3
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 10.10.2008, at 19:02, Stanislav Malyshev wrote:

It should be noted that this proposal builds on Stas previous proposal  
after Zendcon

> 1. Allow braces for namespaces. So, the syntax for namespaces will be:
> a) namespace foo;
> should be first (non-comment) statement in the file, namespace  
> extends to the end of the file or next namespace declaration.
> b) namespace foo {}
> can appear anywhere on the top scope (can not be nested).
> Mixing both syntaxes in one file is not possible. The semantics of  
> both syntaxes will be identical.
>
> 2. Simplify resolution order for classes in the namespace:  
> unqualified names are resolved this way:
> a) check "use" list if the name was defined at "use", follow that  
> resolution
> b) if not, the name resolves to namespace::name
> Consequence of this will be that for using internal class inside  
> namespace one would need to refer to it either as ::Foo or do  
> use ::Foo prior to its usage.


The original 3rd point from the proposal now has the following two  
optional solutions (the first one being the originally proposed  
approach):

> I have two proposals, actually.
>
> 1. Leave functions (and constant) alone, i.e. namespace would ignore  
> that.
> 1.1 Option: if you define function inside namespace, compiler could  
> give an error (I don't like this option, but I mention it for the  
> sake of completeness).

I am -1 on this one.

> 2. Leave functions/constants as they are now, and add the following  
> syntax:
> Class::Name->method()
> for calling static methods (and referring to class constants), so  
> that there would be a way to disambiguate calls in (rare, IMHO)  
> situations where ambiguity may arise.


I am +0.5(*) on this one. I dont like the fact that this means that  
code needs to be migrated before being unambiguous, so I preferred the  
idea of having a different separator between namespaces and its  
members, but this way there is at least a solution available.

(*) There is a condition under which I would be +1 for the syntax. If  
in PHP6 we can make the old syntax (A::foo() and A::FOO) raise an  
E_STRICT (I dont think we ever want to remove it, so E_DEPRECATED  
would not be the right choice), when its being used to reference class  
members instead of namespace elements. If I understand the namespace  
resolution rules properly, we check namespaces first before checking  
for a class with the same name. So with the E_STRICT in place,  
developers could protect themselves perfectly from accidental  
ambiguities (if they were to ever introduce a namespace with the same  
name as a class with a constant or static method that is referenced  
using the double colon) and effectively migrate to the new syntax  
(which I think is nicer anyways, than the original syntax).

---

Barring any new major findings I ask everybody to cast their vote by  
Thursday evening PST. Since Dmitry was not happy with his proposal we  
are left with:

1) Rip them out
2) Keep as is
3) Stas proposal with functions/constants ignored
4) Stas proposal with "->" optionally allowed to resolve ambiguities

If we have a decision by Thursday evening we could hopefully do an  
alpha3 by Thursday the following week, although I would want any  
namespace to be documented before (or closely around) the release of  
alpha3. Stas said that he would be willing to update the README in a  
timely manner after finishing a patch, in case we go for 3) or 4). I  
hope we can also find the time to transfer any changes to docbook  
quickly after this.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org