Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33764
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain bitxtender.com from 80.237.132.12 cause and error)
Cc: Stanislav Malyshev <stas@zend.com>,
 Derick Rethans <derick@php.net>,
 PHP Developers Mailing List <internals@lists.php.net>
Message-ID: <70DFF324-3518-4B13-AC26-619710563F35@bitxtender.com>
To: Jochem Maas <jochem@iamjochem.com>
In-Reply-To: <4756EC80.1070500@iamjochem.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v915)
Date: Wed, 5 Dec 2007 20:27:06 +0100
References: <alpine.DEB.0.98.0712042315260.20300@kossu.ez.no> <4755FB31.2050901@zend.com> <alpine.DEB.0.98.0712050940550.20300@kossu.ez.no> <4756E3AF.2070703@zend.com> <4756EC80.1070500@iamjochem.com>
Subject: Re: [PHP-DEV] RFC: Dropping Namespace
From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=)

+1. Maybe PHP 6, as Sebastian suggested.


David


Am 05.12.2007 um 19:22 schrieb Jochem Maas:

> +1 for putting namespaces on the backburner and taking the time to
> get it 100% right ...
>
> Stanislav Malyshev wrote:
>>> some people like a "misguided" implementation of namespaces. The =20
>>> idea
>>> of namespaces is to prevent collisions in USER land code, not =20
>>> turning
>>> internal PHP classes into a pile of goo.
>>
>> Yes, idea of namespaces is not to turn PHP classes into a pile of =20
>> goo.
>> But what's your point?
>>
>>> I don't quite understand why allowing multiple namespaces is such a
>>> big issue, however - it won't solve the naming collision issue.
>>
>> I'm sorry, I don't understand what you mean by "multiple =20
>> namespaces" -
>> multiple namespaces per file? I object to allowing it for reasons =20
>> having
>> absolutely nothing to do with naming collisions, as anybody =20
>> bothering to
>> actually read what I wrote would immediately know.
>
> this implies that your objections to multiple namespaces per file is =20=

> valid
> whereas objections to the limitation are invalid.
>
> apparently people keep 'flogging this horse to death' because they =20
> are not
> convinced by your wisdom with regard to this decision - they may be =20=

> idiots (me included)
> but they are the majority of your users, so it seems.
>
>>
>>>> That's because namespaces are not executable blocks.
>>>
>>> Neither are classes.
>>
>> Your point being?
>
> that therefore your argue that "namespaces are not executable =20
> blocks" doesn't
> hold up unless your willing to state the inconsistency is one of =20
> your design goals.
>
>>
>>> No, but, do you really need to have such long names? And besides =20
>>> that,
>>
>> Yes. Such names are hard fact of life, I have seen them in many
>> applications and libraries, and I have heard developers to complain
>> about it.
>
> <remark type=3D"OT" class=3D"irrelevant">
> developers will complain, it's in their blood, nothing anyone will =20
> ever produce
> will change that ... somewhere in the future when all code is =20
> created without the
> intervention of man .. even then there will still be a compiler =20
> complaining.
> </remark>
>
>>
>>> you *have* to keep repeating them in every file you'd want to use =20=

>>> them -
>>
>> Once per file, yes. Much better than having to spell out all the long
>> names every time.
>>
>>> Just saying "Yes, they are" is not a very good argument - =20
>>> actually, it's
>>> not an argument at all.
>>
>> No more and no less than "I wonder if they are useful, let's just =20
>> delete
>> them".
>
> actually that is not true - a halfbaked concept is pretty much =20
> garanteed to give you
> and the users of your product more headaches than no implementation =20=

> at all. and
> once the genie is out of the bottle your stuck with it - with all =20
> the BC implications
> of having to support functionality people would rather see changed.
>
> besides possibly having to type a little less, there seems to be =20
> nothing namespaces would
> give us [in it's current form] that we cannot achieve already ... =20
> with the bonus that
> users are currently not restricted in the way they organize/rollout =20=

> their code, at least
> with regard to 'bundling' of files.
>
>>
>>> Actually, it's exactly the opposite, as I avoid naming colissions
>>> (point 1), I don't need to import every class I want to use (point =20=

>>> 2),
>>> and can group all my classes together in one file (point 3).
>>
>> Of course, if you don't want to hear about namespaces, nobody can =20
>> force
>> you. However, all of your points (avoiding naming collisions, not
>> needing to import every class you want to use and ability to group
>> classes together) is exactly how namespaces work right now. If you
>> refuse to learn about it, it can't be helped, however that just means
>> you deny yourself a very useful tool.
>
> conversly - when namespace functionality is released, every =20
> developer will be confronted
> with any problems they might bring with them, at some stage, because =20=

> there will be third
> party code out there that uses namespaces (code which for the sake =20
> of argument one would
> be required to use under some circumstances).
>
>>
>
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
David Z=FClke
dz@bitxtender.com
Tel: +49 (0)89 57 08 15 15
bitXtender GbR
Paul-Heyse-Stra=DFe 6
80336 M=FCnchen