Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40318
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: <48C430A6.8060307@iamjochem.com>
Date: Sun, 07 Sep 2008 21:51:02 +0200
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: PHP Internals List <internals@lists.php.net>
References: <0E6B0C09-99C4-4843-A8E6-0B015EB98B4E@pooteeweet.org> <D1E82261-4055-4A09-9337-97C3E2248F39@pooteeweet.org>
In-Reply-To: <D1E82261-4055-4A09-9337-97C3E2248F39@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] namespace RFC
From: jochem@iamjochem.com (Jochem Maas)

Lukas Kahwe Smith schreef:
> 
> On 31.08.2008, at 15:37, Lukas Kahwe Smith wrote:
> 
>> Hello all,
>>
>> All the recent discussions about namespaces, have left many of us 
>> wondering if our implementation is rock solid or not. However the 
>> discussions were not really well organized. This is why I am thankful 
>> that Marcus and Felipe have spend the better part of this Sunday to 
>> write an RFC [1] that hopefully summarizes all the key concerns. Also 
>> they have created a patch that they feel addresses the concerns.
> 
>> [1] http://wiki.php.net/rfc/namespacecurlies
> 
> I have also asked in my blog about practical experiences from people 
> using PHP 5.3.0 with namespaces in development:
> http://pooteeweet.org/blog/1288
> 
> The gist in the first 2 responses seem to be that they are ok with the 
> current state of things.

they both admit they don't do (or are not interested in) the major point
the RFC tries to tackle (i.e. file concatenation).

subsequent posts do point out problems:

1. "non-deterministic" (a.k.a error prone) __autoloading issues

- IFAIC Greg's arguments are sound, Stanislav's performance arguments are bogus
(imho) simply because, up until the point that the new functionality is
stable, complete and devoid of the WTF-factor it's performance should be
ignored ... make it work, then make it fast?

2. namespaced constants/functions not autoloadable
3. namespaced functions not aliasable
4. the abiguity with static methods and namespaced functions

- Elizabeth states this very succinctly.

5. inordinate number of use statements
6. internal classes being 'favored' over user classes.

- which is likely to mean people will either avoid namespaces, avoid use statements
or worse still miss a use statement now and again ... see point 1.

If you ask me a major issue stems from the fact that the namespace scope operator
was chosen to be the same as the class scope operator, even if this incurred no technical
problems (which, I think, point 4 is), it still incurs the potential for major WTF when
simply reading code - at the very least having to constantly check the 'use' statements
at the top of a file to determine the actually referred to 'element'.

Lukas, you stated a while back you were nervous about the namespace functionality,
I believe you are right to be so. what there is currently will most likely do the
opposite of what it is intended to ... the intention being, I assume, to increase php's
'enterprise level' functionality & appearance (in terms of suitability).

rgds,
Jochem

PS - please be a Dictator! currently it seems that the dev that shouts the loudest gets
to shove his opinion/implementation down everyone's neck regardless of anyone's
objections (however sound) ... even when those objections come from other devs,
which makes a farce of the concept of meritocracy, besides nothing about open source
suggested it's development process needs to be done by commitee.

the more I think about it the more I believe php would benefit from a benevolent
dictator ... who that might be is a more difficult question to answer, one steeped
in politics. I could offer about 3 names that I think would suit the position,
but I doubt anyone of 'importance' has read this far and if they had they probably
attribute about as much weight to my opinions as they do to the average life of an ameoba.

> Anyways, anyone who cares should make their opinion known on this list 
> as clear as possible by Monday (if someone is aware of a good discussion 
> outside of internals please also let us know), so that Johannes and I 
> can make a decision no later than Tuesday without having to feel like 
> dictators. Personally at this point I would leave things as is for now, 
> move to beta and hope that this also increases the number of end users 
> testing and giving feedback. While I hope that we dont have to do big 
> changes after going to beta, if feedback makes it necessary, we 
> obviously have to accept it.
> 
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org
> 
> 
> 
>