Re: namespace RFC

Hello Stanislav, Tuesday, September 2, 2008, 9:58:15 AM, you wrote: > 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). Yet, both are a means of deployment. Which is why I mentioned that. If you do concatenation purely for speed then Phar is not the way to go. > 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. It controls naming and name lookup. End of the story. Current version looks like a misspelled version of labels and alternative syntax which simply adds confusion. > 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). I don't know it either, it is something that came up several times so I put it into the RFC. > 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. I am sorry but I absolutely fail to see how the following is in any way whatsoever unclear: ==== Proposal and Patch We propose to add namespaces as block structures and drop 'namespace foo;' in favor of 'namespace foo: ; endnamespace;', as in this patch. The tests are provided in a second patch. In a second step nesting namespaces should be supported. This can easily be done by simply removing the corresponding error messages. ==== > 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? namespace A::B::C::D::E::F; $obj = new G; Now what? > [...bla...] > Regards, > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com Best regards, Marcus