Hi!
So I ask you all to review the RFC and provide feedback. If you feel
Here's my feedback on the RFC.
1. The RFC seems to assume or imply that PHP programmers have extensive
C++ experience. IMHO it is not true for the majority of PHP programmers.
2. Phar has nothing to do with file concatenation, as if was noted, and
concatenation's use is entirely unrelated to phar (and, before you
mention it, to bytecode caches - they can be used together, but one does
not preclude the other).
3. Namespaces are *NOT* code flow control structure. Giving it a syntax
of a control structure is misleading, requiring "endnamespace" at the
end of each file makes no sense and just adds busywork for people. It
also is awfully ugly - braces at least have some decent looks...
Namespace also is not like a label in any way - it does not specify
point in code and you can not jump to it using either conditional (like
switch/case:) or unconditional (like goto) branch.
4. I did not understand first paragraph of part named "Statements
outside namespaces" - what is has to do with caches? Could somebody
explain it to me (private mail/IRC/IM OK).
5. I am not sure which exactly code RFC proposes to allow outside
namespaces, in any case I don't see why it is necessary to allow any
code to be put outside namespaces in namespaced files. For include, it
doesn't matter anyway, since included file has its own namespace, for
the rest I'm just unclear what else is proposed, please explain.
6. Comment about "we kind of allow nested namespaces" because we allow
namespace in included file is wrong. These namespaces live absolutely
separately and are not nested in any meaningful way. All files in PHP
except for the head script are obtained by means of include(), so it is
only natural that namespace is allowed inside include - it would be
useless otherwise. Included file, however, creates it own namespacing
scope, and just as we do not say we allow nested classes because file
defining class can be included from inside any other class, same holds
for namespaces.
7. Nested namespaces. I see that RFC authors chose to completely ignore
all my comments about namespace nesting, so I repeat them again for the
record.
Nesting namespaces implies hierarchy, hierarchy implies hierarchical
resolution, so if you inside namespace A::B::C::D::E::F, then name G is
expected to resolve when it means either A::G, A::B::G, A::B::C::G, etc.
Combined with autoloading, this makes resolution process prohibitively
expensive, and not resolvable in runtime by any means - since even if
you wrote A::B::C::D::E::F::G it could still mean
A::B::C::A::B::C::D::E::F::G - since you have not one-level resolution
but hierarchical resolution, even qualified name could be partial name.
Making nesting without hierarchy doesn't make any sense - why nest then,
what purpose would it serve?
Another objection for nesting would be that there's actually no
practical use for it in real code - as you could not nest across file
boundaries, only use would be if you pack substantial number of classes
from different modules into a single file, which usually is a bad idea.
If you follow standards accepted by many common applications and
separate classes in different files, nesting is completely useless, so
it is if you group closely related classes (they would probably then be
in the same hierarchy level).
So, summarily, right now I see serious technical challenge for nesting
(hierarchical lookups) and I don't see real use case for it.
Regards,
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
