Re: cvs: ZendEngine2(PHP_5_3) / zend.h zend_compile.c zend_compile.hzend_constants.c zend_execute_API.c zend_language_parser.y
zend_vm_def.hzend_vm_execute.h /tests bug42802.phpt bug42819.phpt bug43332_1.phpt class_alias_021.phptns_002.phpt ns_004.phpt n

Stanislav Malyshev wrote: > Hi! > >> 1) commit of namespace brackets support >> 2) review by Stas for any problems >> >> Once these two things are done, I'll commit. For those interested, I >> have a draft up at >> >> http://pear.php.net/~greg/nsdocs/language.namespaces.html > > In general, good work, thanks! My notes: > > 1. namespace\ is not operator. It's a keyword, which can be used instead > of current namespace name. fixed > 2. Sub-namespace is an unfortunate name - there's nothing "sub" in > MyProject\Sub\Level, maybe better to call it "multi-component names" > etc. In general, single- and mutli-component names work exactly the > same, so I'm not sure they should have separate chapters - just show in > one chapter that name can be foo or foo\bar\baz and that's it. Actually, <?php namespace My\NS\interfaces { interface FooInterface {} } namespace My\NS\Sub { const CONSTANT = 1; } namespace My\NS { class FooImplementation implements interfaces\FooInterface { const $a = Sub\CONSTANT; } } ?> demonstrates PHP working as if it had sub-namespaces. In addition: <?php namespace FooBar { class Blah {} } namespace Foo\Bar { class Blah {} } use Foo\Bar; use FooBar; ?> Shows that a namespace name with \ acts very differently from a namespace name without \ in imports, so I don't think it is entirely accurate to say that PHP namespaces don't support sub-namespacing. We probably need to talk further about this point before I commit. > 3. In "Using namespaces: Basics" the fallback should be mentioned > immediately, otherwise readers that don't read whole page would not know > it exists. fixed > 4. Many examples have \\ inside single quotes - this should be fixed. In > single quotes, single slash is enough. fixed > 5. I don't like "echos" when describing output - maybe better > "outputs"? fixed > 6. Import chapter should mention special case of: > use \GlobalClass; > which can be used to use GlobalClass without qualifying (unlike use fixed > GlobalClass which is just a NOP). Also, it'd be nice to explicitly say > that even though you can use both My\Full\Classname and > \My\Full\Classname, they are the same in this context since imports do > not need qualification. actually, "use \Long\Classname;" is a parse error - did we intend to allow it? > 7. In rules, imports influence all class names, both qualified and > unqualified. They do not influence fully qualified ones, though - like > \foo\bar. fixed > 8. namespace\Foo is a fully qualified name too. fixed > 9. "Inside namespace, calls to unqualified functions that are defined in > the current namespace and are in the same file are interpreted as calls > to these namespace functions, at compile time." - IIRC this is not true > currently. You're right. deleted. > 10. items 7 and 8 say basically the same. And autoloading is part of > looking for the class, so it's not two-step process, actually - it's > one-step process which applies to all class names, and the class name is > always resolved compile-time, no matter what. Combined and refined. > 11. Undefined constants that are not qualified can be substituted as > string (echo FOO outputs FOO), but any qualification would lead to > undefined constant produce an error. added to pitfalls. > 12. I would not call not nesting namespaces "pitfall" - it has a meaning > of unexpected negative effect, but we actually did it intentionally. > Maybe "limitations" or "restrictions"? I'm going to rename this to FAQ > 13. "Dynamic namespace names (quoted identifiers) should escape > backslash" should be "Use single quotes!" added. > 14. Somewhere we should mention you cannot override special constants > like NULL, true, false, etc. added. Greg