As a developer and member of the community, the following is my two-cents on
the subject:
On Dec 4, 2007 5:16 PM, Derick Rethans <[EMAIL PROTECTED]> wrote:
> 1. As it is impossible to do "use XXX as NativeClass" we get to the
> point where we'd have to namespace new internal native classes
> otherwise we might introduce BC breaks....
>
> Basically prefixing the classnames... This you can already do just
> fine without namespaces.
I agree. If the solution to this is to start adding prefixes to the aliased
names, then namespaces lose part of their purpose.
2. You have to import every class yourself. You can currently not do:
>
> use myNamespace::* as *; // or similar syntax
>
>
Globbing of this nature, in my humbled opinion, would not be the best idea
because of the high potential of problems. But, in the same respect, with
very large applications, it is much more preferable than to manually include
possibly hundreds of namespaces.
> 3. We keep bickering over using { } or not, multiple namespaces in a
> file or not... etc. I understand that people want more flexibility,
> but also we need a *simple* to explain implementation. With the
> current implementation I see the following problems here:
>
> - You can't stick multiple namespaces in one file
> - Unlike other constructs in PHP that mark executable blocks,
> namespaces don't use { }.
> - The "namespace" keyword at the start of a file is somewhat magic,
> because it can only appear as first element in your script.
I think this is a huge issue, if only for consistency with other constructs
of the language. There are already three different ways to write an
if/switch/while/for/etc condition: 1) With braces, 2) Without braces, and 3)
Alternate colon syntax (i.e., if ($blah == true):). Maybe namespaces should
conform to the existing conventions instead of introducing a new one that is
likely to just add yet another layer of confusion.
The same can be argued for the multiple-namspaces-per-file argument. If I
can put more than one class in a single file, then I should be able to put
more than one namespace in a file. Performance gains/losses aside, this is a
coding convention, and maintainability starts with consistency.
> 4. What is wrong with simple prefixes in the first place? Both PEAR_*,
> Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
> 'namespaces'. We could optionally create a registry on php.net for
> this to avoid conflicts.
>
The only difference, on the surface, that I see with namespaces vs. standard
prefixing is that namespaces has a new keyword and changes the separator
from an underscore to the double colon. Beyond that, without the other
features, namespaces doesn't sound very interesting as a feature of the
language, so as a developer I wouldn't feel compelled to use it in any
capacity.
> With all the above considerations, especially my first point, I still have
> not
> heard any good reason why namespaces in the current implementation are
> actually
> useful - or what particular case they solve... so I am wondering, are they
> really useful? I come now to the conclusion that they are not, and for
> myself
> (and most likely my work projects) I would have to decide not to go with
> namespaces, but instead stick with the 3 letter prefixing. Something that
> I
> have totally no problem with, as it is nice and easy.
>
For what it's worth, I would have to completely agree with Derick on this
issue. It just seems that namespaces could be made to do much more than it
already does.
--
It looked like something resembling white marble, which was
probably what it was: something resembling white marble.
-- Douglas Adams, "The Hitchhikers Guide to the Galaxy"
