Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40648
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: <48D961CA.4030804@iamjochem.com>
Date: Tue, 23 Sep 2008 23:38:18 +0200
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: Kevin Waterson <kevin@phpro.org>
CC: internals@lists.php.net
References: <59.6C.35835.FB3F8D84@pb1.pair.com> <20080924065741.50a30448.kevin@phpro.org>
In-Reply-To: <20080924065741.50a30448.kevin@phpro.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] true namespaces, yet another point of view
From: jochem@iamjochem.com (Jochem Maas)

[[@devs: nothing of technical importance in this email, but it might
make you feel better :-) ... even Stas!]]

Kevin Waterson schreef:
> This one time, at band camp, "jvlad" <dmda@yandex.ru> wrote:
> 

everything that jvlad wrote was way too vague for me to understand
so I couldn't possibly comment on it.

> 
>> May I suggest something in this area?
> 
> May I suggest something also.. Lets just let namespaces die and let
> it become a repressed memory as it seems it is more trouble that it
> is worth. Seriously.

why does the ammount of trouble other people take upon themselves matter
to you? ... and "repressing memory" is very bad advice (but that's rather esoteric).

> For 10+ years we have got on just fine without them, and the amount
> of work to get a second-best implementation that nobody agrees on
> hardly seems benificial. The gains of namespaces are minimal at best,
> because a few cannot be bothered with some simple prefixing.

the gains are in the eye of the beholder, beyond the issue of symbol
name collision avoidance there is big a real issue with
very_very_very_very_very_very_very_very_looooooooooong_symbol_names
... it's a proven fact it becomes increasingly more difficult to
grok lines of code as they increase in length ... namespaces offer a
mechanism to mitigate overly long lines (at the cost of some obsfucation).

you may decide the gains are minimal and not worth pursuing personally,
but plenty of others feel the exact opposite. I'm personally a little
ambivelent regard to inhouse code but I do envisage that libs like PEAR and
ZF will become much more appealing when they take on namespaces, as such I
care about whatever it [namespaces] becomes being 'good' .. because either
way, sooner or later, I will be confronted with using them even if I don't
use them in code I write myself. (my stance makes sense to me but It's
likely I'm not expressing it very well!)

> PHP 5.3 release is looming, and there is STILL conflict about implementation.

1. conflict is everywhere, even outside of the world of php functionality implementations.
2. that 5.3 is 'looming' has surely not escaped the RMs
3. shouldn't 5.3 be release when it's ready rather because people expect it to be?

> The current approach is a long way from what was thought of as namespace
> support and it seems nobody is completely happy with any model that
> has been put forward. 

what exactly was thought of as namespace support? whatever it is exactly
it is apparent that's it's wide open to mis-interpretation ... this is
something to be tackled with documentation.

I don't think the 'model' has been under attack, rather a number of
ambiguity issues which were not fully foreseen ... issues which I might
add are due in no small part to the 10+ years of baggage php has collected.

it's easy to throw out the word 'namespaces' and assume everyone is on
the exact same page ... it's rather harder to actually build something people
are willing to call 'namespaces' ... the fact that it is hard and that the
discussions have been long and difficult do not of themselves mean the
effort and the impending result are not worthwhile.

> The current implementation is nothing but a series
> of comprimses, 

actually there has been very little comprise, that's one of the things the
lead developer has been taking lots of flak for.

> each one taking away a little of the functionality that
> was first envisaged.

the only thing that has been proposed to be taken away is functions and
constants ... both of which can be incorporated at a later date
(without the stress of release deadlines and having to deal with additional
BC issues, imho), I personally think a phased introduction of namespacing
functionality is not a bad thing, granted getting everything in one go
would be nicer but at the end of the day you can't shoot yourself in the
foot with a gun you don't have.

the other major issue revolved around name resolution order upon which
consensus has been reached in fact AFAICT (I've read everything that's been
written AFAIK).

> Lets just let it die. It is un-needed, un-wanted by many, and the end 
> result seems to be less that optimal, or even a true implementation
> of namespaces.

I would offer that bandying about subjective opinions as to what is wanted,
what is true, etc, etc as being objective fact is one of the things that needs
to die more than anything else. php counts it's user's in the 100,000's if not
1,000,000's ... I'd hazard to say that it's nigh on impossible to get accurate
stats regarding namespace support.

rgds,
Jochem