Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:40625 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16029 invoked from network); 23 Sep 2008 08:38:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Sep 2008 08:38:29 -0000 X-Host-Fingerprint: 85.176.190.20 e176190020.adsl.alicedsl.de Received: from [85.176.190.20] ([85.176.190.20:27214] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DA/4F-35835-40BA8D84 for ; Tue, 23 Sep 2008 04:38:29 -0400 Message-ID: To: internals@lists.php.net Date: Tue, 23 Sep 2008 10:38:25 +0200 User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 References: <48D7F5EF.3090202@zend.com> In-Reply-To: <48D7F5EF.3090202@zend.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 85.176.190.20 Subject: Re: namespace issues From: karsten@typo3.org (Karsten Dambekalns) Hi. For what it's worth, my point of view: Stanislav Malyshev wrote: > 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). Full support for the braces, but please *do*not* allow both ways. Why? Perl's "more than one way to do it"? If there's one way, it's clear what to use. I see absolutely no point in this. Really. Please don't. > 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. Fine with me. I'd use ::Foo for internal classes anyway to avoid speed and ambiguity issues. > 3. Functions will not be allowed inside namespaces. We arrived to > conclusion that they are much more trouble than they're worth, and > summarily we would be better off without them. Most of the functionality > could be easily achieved using static class methods, and the rest may be > emulated with variable function names, etc. We roll everything in classes anyway, so fine with me. Regards, Karsten