Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41508
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 69.16.228.148 cause and error)
Message-ID: <1DF48FCDC8504BAC8131DD96191A7249@pc>
To: <internals@lists.php.net>
References: <69907CB6763C4164A1AE82D659B80286@pc> <5A.30.00734.70AF6094@pb1.pair.com> <6fef9b880810280535j43bcbdbvef2531f471578697@mail.gmail.com>
Date: Tue, 28 Oct 2008 14:46:32 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Clarifying the resolution rules
From: sv_forums@fmethod.com ("Stan Vassilev | FM")

> We are going to ignore the inherit problems that calling
> file_get_contents(__FILE__); would cause...
>
> Also, I disagree with a PHP namespace. the looseness of the language
> is one of its strong points. Some things should be made strict, I
> agree, bit it start with a php namespace and where does it end? If
> your not careful you end up with c# or java where doing anything
> requires going through hundreds of classes and packages.

Please let's avoid bad comparisons :P

We need to be very well aware that the concept of namespace in its simple, 
clear, understandable form, represents:

1) no globals, everything in the namespace is in the namespace, including 
vars, constants, functions, classes and nested namespaces.

2) to refer to a global namespace, there's no magical fallback to another 
namespace (the global one), you need to "use" it specify it in your call 
explicitly. The very idea of namespaces is, that other names don't leak into 
your namespace.

3) we'll likely see in a future edition of PHP (5.4? 5.5? 6.0?) that many 
currently global functions with "pseudo namespaces" like array_*(), 
string_*() etc will gain concurrent aliases in a namespace:  \array\*() 
\string\*()   since if we keep adding stuff in globals, then why introduce 
namespaces at all?

4) any fallback, fudge, name leak, partial implementation represents 
complication of the namespace concept, it's a compromise that makes 
namespaces harder to implement, understand and use, but easier in the short 
term for porting code and the "global functions all over the place" issue 
PHP is so often criticised for.

So, while I remain flexible on the scale of the options, I really wish 
people don't just think in the short term, since short term solutions are 
what caused the necessity to use "\" instead of "::" in the first place. 
When you're cornered by your ill past decisions, you either break BC (which 
we don't want to do), or add more WTF-s to the language as it evolves.

Regards, Stan Vassilev