On Dec 5, 2007 12:04 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > collision problems that class naming and function naming have. Only
>
> Only if you insist on *not* using the namespaces to solve collision
> problems. For the 1001th time - you can not expect to put all names into
> global space and have the language by some magic to sort it out and go
> both ways. One name can mean only one thing, namespaces or not.
> Namespaces just allow you more convenient rules for defining what name
> means what thing.
I would like to second this notion. There are those who would say
that the global namespace is for the use of PHP itself. I would
disagree heartily, PHP as a language is built to serve the developer
who is using it. They should decide what exists in the global
namespace.
When I write a library I will often create functions/classes/variables
that have no business being used outside my library. So I don't see
the need to make the names longer just so I don't collide with someone
else's internal variables/classes/functions.
This paves the way for doing much more advanced things with packages
and run-time loading of code (which I know some people will think
isn't good).
Of all the namespace talk I've heard, the only part I disagree with is:
use Foo::Bar as OtherBar;
This seems like a maintainability nightmare to me as well as having
well having some possible BC issues long-term. If you don't like
someone's class name that much that you have to alias it then just
make your own wrapper class:
class OtherBar extends Foo::Bar {}
Its not like it is that many more characters to write.
So if we have to wait until PHP 6 to get this right, then so be it. I
just see this as being critical to the future of enterprise/large
scale PHP and don't want to see it die.
--
-Nathan Gordon
If the database server goes down and there is no code to hear it, does
it really go down?
<esc>:wq<CR>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
