Sounds sweet. However, I already found a problem there, it has to do with aliasing. Lots of code (libraries) will, even inside the same class, use the class name for method calls instead of the "self" keywords for various reasons. This will break if the user decides to alias the class and use it, I guess. Other than that, I don't see any problems so far. Does a My:Nested:Namespace:Class::staticMethod() work?
Nice work man, keep it up, let's hope we can finally have some namespaces/packaging support in PHP ;) I wish you luck. +1 from me. - David P.S: check out http://article.gmane.org/gmane.comp.php.devel/29492, might be of help, dunno > -----Original Message----- > From: Jessie Hernandez [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 07, 2005 2:44 AM > To: internals@lists.php.net > Subject: [PHP-DEV] YANP (Yet Another Namespace Proposal) > > I have locally made changes to support namespaces, with minimal impact to > the Zend Engine (I based my changes on PHP 5.1.0b2). I have gone through > the archives and read the previous discussions about namespaces and the > outstanding issues, and to the best of my knowledge, I think my changes > solve these. > > I have only a few things to finish (as I'll explain below), but so far > everything's working great (I have only enabled classes to be under > namespaces, since that's all I care about, but functions and constants can > be added in a similar manner)! Since I still have some things to finish, I > won't post a patch yet, but I'll give a high-level description of what I > did to see if my approach is acceptable or not. > > Basically, my approach involves the following concepts: > > - Classes may not contain colons (no change here), BUT class name > references > CAN contain colons (this is KEY!). > - All imports are done at compile time. > - Imports only affect the current file (yes, this has been done!) > > Here are some more details: > > Class Table Manipulation > ------------------------ > When the start of a namespace declaration is encountered, the namespace > name > is saved in a compile global variable. All classes inside the namespace > block will get the namespace name and the colon prepended to the name > (this > is done in "zend_do_begin_class_declaration"). So, for the following code: > > <code> > namespace my_namespace{ class my_class{ public $mem; } } > </code> > > What will actually happen here is that the class will get added to the > class > table as "my_namespace:my_class". > > > Referencing Classes > ------------------- > The following two examples are valid: > > <code> > $a = new my_namespace:myclass(); > </code> > > <code> > import my_namespace:myclass; > $a = new myclass(); > </code> > > > Imports > ------- > The syntax for the import statement will be: > > import <full-class-name> [as <alias-name>]; > > I have not yet added full namespace imports ("wildcard" imports), and am > not > yet sure if this is a good idea. Anyways, with the import statement, if no > alias is specified, then the class is imported with the remaining string > after the last colon in the name, and if an alias is specified, then that > name is used (aliases cannot contain colons). For example: > > <code> > import my_namespace:myclass; > $a = new myclass(); > </code> > > <code> > import my_namespace:myclass as my_namespace_my_class; > $a = new my_namespace_myclass(); > </code> > > When an import is done, what happens is that the import is saved in an > import hashtable, which holds the "aliases" which are active for the > current file. The alias is also saved in class_table (an additional entry > is added, the key being the alias name and the value being the > zend_class_entry for the actual class). This means that a zend_class_entry > can belong to more than one key in class_table at a time (this is done to > emulate that a class by that name actually exists, and it also prevents > classes in the global namespace to be named the same as import aliases). > > Now for the interesting part! How are imports done on a file scope only? > The > key to this is that file scopes can be emulated at compile time, but not > at > run time. As I said before, imports are saved in a compile global > hashtable. When the end of the file is reached, this hashtable is cleared > and the alias entries are removed from class_table. This is done simply by > modifying the start rule: > > start: > top_statement_list { zend_do_unimport_all(TSRMLS_C); } > ; > > This triggers the "zend_do_unimport_all" function to be called at the end > of > the file. At this point (before the function is called), all references to > imported names have been changed internally to full class names, which > include the namespace and colon(s). Since include/require statements are > executed at runtime, when the "zend_compile_file" function is executed for > the included files, the import hashtable will be empty! > > I have not yet begun doing this, but I would like the import statement to > actually include the file where the class is defined. A new php.ini > variable called "class_path" will be used for this. When an "import > my_ns:my_class;" statement is encountered, the file > "<class-path>/my_ns/my_class.php" will be included (of course, multiple > directories can be specified in the class_path, just like include_path). > > > The above changes make a minimal impact to the Zend engine, and since all > the namespace/import translation is done at compile time, execution speed > is not affected. > > I would like to gather comments/suggestions/criticisms of the above > approach, in order to see if I should continue making these changes or > not. > If there is enough demand, I will post the patches of what I have so far, > even though it's not complete. > > > Regards, > > Jessie Hernandez > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
