I agree, I also see this as critical in large applications. The current
implementation may have some problems, yes, but it's not hurting anyone
who's not using namespaces.
The minor issues around namespaces can be worked out in due time, but I
think it would be a huge mistake to drop the whole idea. Most
programming languages have some type of namespace implementation, there
is obviously some usefulness to it.
My personal opinion:
- Allow multiple namespaces per file (mostly for bundling). Personally,
in my application, this cuts execution time literally from .18 seconds
to about .04. Microseconds, but with alot of users this would definitely
be beneficial.
- Braces or declarations like the current, it doesn't matter. However I
think it is important to be able to use the same namespace in different
blocks, allowing functions to be declared under the same namespace in
different files. Declarations like it is now seem fine.
- Some type of import X as Y statement might be useful, but would be
very easy to abuse. Some people would import too much and defeat the
entire purpose of namespaces. I don't have much of an opinion on this.
In essence, I believe keeping namespaces is a necessity. The only useful
feature I have seen people talking about is multiple namespaces per
file. I also saw a patch on here for it (only about 5 lines of actual
code changed by the way), I set it up on PHP 5.3 and I've been using it
for about 8 hours of constant development and testing with no problems
whatsoever.
On Wed, 2007-12-05 at 14:10 -0600, Nate Gordon wrote:
> 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
