Hello Alex, Monday, July 25, 2005, 11:48:33 PM, you wrote:
> Hi Jessie, > first, while your patch applied cleanly (except zend_vm_opcodes.h, which > is generated) the build broke with: > bison -y -p zend -v -d > /mnt/home/alex/cvs/php-namespaces/Zend/zend_language_parser.y -o > Zend/zend_language_parser.c > conflicts: 5 shift/reduce > /mnt/home/alex/cvs/php-namespaces/Zend/zend_language_parser.y: expected 4 > shift/reduce conflicts > *** Error code 1 > I had to increase the expected shift/reduce conflict count to 5 to > continue the build, which then completed successfully. > On Wed, 2005-07-20 at 00:05 -0400, Jessie Hernandez wrote: >> Also, import statements now include the class files, using a new .ini >> variable, "class_path". Files under the directories in the class_path have >> the namespace names as directories and the class names named exactly as the >> file that declares it (like Java), e.g. my_ns:class1 is declared in >> $class_path/my_ns/class1.php. > I don't like this idea; it restricts the developer to this Java-like > class / directory layout. It also restricts him to name his files after > the scheme you defined (which is <classname>.php) - many use other > schemes. Shouldn't PHP let you be free in this kind of decision? I think > yes, especially, as this could also be implemented with the __autoload > function in user-space. You already have the ability to overload __autoload or provide several userspace __autoload functions that would be called one after another until the first succeeds. What else do you want? Besides the fact that i am still convinced that we should find a way to pass the full namespaced name to __autoload instead of just the classname. If you ask me not doing so is simply an error. >> Again, the only missing feature I know of is "namespace imports". I've been >> thinking about it, and I think the best approach is actually very simple. > Here's another one: the script > <?php > $foo= 'Foo:Bar'; > import $foo; ?>> > gives me > [EMAIL PROTECTED]:~/cvs/php-namespaces# sapi/cli/php > ~/tests/classes/dynamic_import.php > Parse error: parse error, unexpected T_VARIABLE, expecting > T_NAMESPACE_NAME or T_NAMESPACE in > /mnt/home/alex/tests/classes/dynamic_import.php on line 3 > (IIRC Stanislav Malyshev already mentioned this in the YANP-thread > already.) I don't see any reason to allow this. PHP is already far to dynamic (which already prevents some speed improvements to the engine). Namespaces are a means for working with several frameworks/libraries at a time and for spreading/controlling responsibilities. In all those cases you definitively won't need the above and its presents would circumvent what we'd achieve here. Best regards, Marcus mailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
