Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40628
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain iamjochem.com from 194.109.193.121 cause and error)
Message-ID: <48D8BD64.8040703@iamjochem.com>
Date: Tue, 23 Sep 2008 11:56:52 +0200
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Dmitry Stogov <dmitry@zend.com>
CC: Greg Beaver <greg@chiaraquartet.net>, 
 Lupus Michaelis <mickael+php@lupusmic.org>,
 internals@lists.php.net
References: <48D47532.8080102@chiaraquartet.net> <e666c3890809200924t28f1c585kad77729dd608c5ad@mail.gmail.com> <10845a340809201643q59e27211i471e09241f7253b1@mail.gmail.com> <200809202000.38870.larry@garfieldtech.com> <E5.0A.65213.536E5D84@pb1.pair.com> <48D66160.40306@chiaraquartet.net> <48D79672.4060208@zend.com> <48D79B9D.2080703@iamjochem.com> <48D7A5C8.7070503@zend.com> <48D7EEE8.2060701@iamjochem.com> <48D8A542.1080500@zend.com>
In-Reply-To: <48D8A542.1080500@zend.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethod
 class constant/ns constant
From: jochem@iamjochem.com (Jochem Maas)

hi Dmirty,

>>
>>>>> I really don't see a reason to change namespace syntax into a less
>>>>> intuitive way. 
>>>> I don't think the current implementation is intuitive, the ambiguity
>>>> issues,
>>>> (and possibly the name resolution order, although I can't grok what the
>>>> current
>>>> state of that is) are rather large WTFs.
>>>>
>>>>> Your speed degradation argument isn't truth. The
>>>>> ambiguity problem exists, but it is just an ability to use php in a
>>>>> wrong way. Just don't create conflicting names.
>>>> which begs the question, what was namespaces created for?
>>>> (that's a serious question because your statement has me truly confused)
>>>>
>> you didn't answer the question (and AFAIC the readme doesn't either).
> 
> The main reason of namespaces is resolution of name conflicts and
> ability to use the same names in different scopes.

thank you for confirming this explicitly.

> 
>>> README.namespaces was committed into PHP_5_3 about year ago.
>> a 14 month old document which doesn't cover the status quo,
>> and begins with a disingenuous statement about the problem namespaces
>> try to
>> solve (is that really all there is to namespaces? to avoid typing long
>> class names?
> 
> Yes, you are right. It's need to be adopted to current situation which
> might be changed once again...

okay :-) ... I did actually promise Lukas that I'd write a guideline/best-practices
doc regarding namespaces ... I still intend to give that a shot, It will require
that people like you and Stas (amongst others) give a little time to vet the
doc for accuracy, do you see this as a problem?

>> most people have auto-complete features in their editor to take care of
>> that 'problem'
>> and it really doesn't explain why constants or functions exist in
>> namespaces at all.)
> 
> I see you point, and you might be satisfied with decision which is going
> to be final, however from my point of view function and constants must
> be allowed in namesapaces just because they are parts of the language.

I would prefer to have functions and constants in namespaces, but I think the
current implementation requires greg's patch in order to make it work.
additionally I think autoloading for functions (and actually anything namespace
related) should be seriously considered. the fact that it's only classes that can
be autoloaded and namespaced is of itself consistent. there is something to be said
for this kind of clearly defined 'limitation' - you know where you are!

that said I think dropping functions (and constants) is the only real alternative
to allowing greg's patch. dropping them may mean an incomplete namespace implementation,
but in this case it's a good thing ... it allows people to start using namespaces
and allows you (php devs) to work out a means to solve the ambiguity issues
surrounding NS funcs/constants without worrying (as much?) about BC issues and
without a barrage of 'wtf' type bug reports and questions (users will
push namespaces to the edge and beyond if you give them the chance, not
introducing funcs/constants means they can't simply can't do certain things for now)

in the long run functions and constants will be added to namespaces ... and then
the ambiguity issues will have to be dealt with. I believe Greg's namespace member
concept will be required even if the syntax is/must/should/will changed to
something everyone finds acceptable.

rgds,
Jochem