Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40638
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: <48D8EDE5.9000802@iamjochem.com>
Date: Tue, 23 Sep 2008 15:23:49 +0200
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Lester Caine <lester@lsces.co.uk>
CC: PHP internals <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> <48D8BD64.8040703@iamjochem.com> <48D8C3ED.60200@lsces.co.uk>
In-Reply-To: <48D8C3ED.60200@lsces.co.uk>
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)

Lester Caine schreef:
> Jochem Maas wrote:
>> 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.
> 
> Did you really mean to say that.

funnily enough yes.

> 
> Push namespaces out now - incomplete - and then change them again later?

it's not imcomplete anymore than autoload() is incomplete (autoload() also
doesn't cater for functions). and it's not *change later* but *extend later*
whereas if one would roll out the currently implementation with functions/constants
you would have to *change it later* to fix the ambiguity issues (which is hard to
do in a way that satisfies anyone, see reactions to Greg's namespace member
proposal as a perfect example of the ammount of friction that one needs to
overcome). changing it later implies that people will have to fix their code
upon a new release of php at some point because they have been using
namespaced functions/constants.

if they can't use something then they don't have to change the code that
doesn't use it either.

> Why should we even bother using them if they don't do the whole job and 
> are going to change again. 

not *changed* but *extended*. it seems obvious that BC dictates that stuff put
out the door shouldn't be broken willy nilly. granted this will probably make
it more difficult to come up with an alternative to Greg's proposal that also
satisfies the ambiguities issues yet does not force syntax changes on developers
using namespaces with released versions of php ... but that's not your f***ing problem
is it? that'll be up to people like Stas, Greg, Dmitry et al to actually hammer
out a solution.

> Things like PHPEclipse and phpdocumentor need 
> some major work to support this extra level, and that can't start until 
> the format has been fixed - and now even that is not certain ?

... same argument as above.

I'll grant that my argument/opinion may be incorrect but I'll leave it up to
the guys who build php to call me out on that.