Namespaces: - alternative

Following Zeev's announcement that at the moment Namespace will probably be dropped in PHP5/ZE2, below is a short RFC on a replacement idea for it.. - Although this has been hashed out many times on the ZE2 mailing list, I'm cc'ing to PEAR to see if anyone has any ideas feedback, for this.. --------------------------------------- Requirements: a typical PEAR package. class This_Is_The_Package { .... } class This_Is_The_Package_And_Some_SubClasses { } At present, this class names can be very long, and when dealing with a package which has a long name and a large number of subclasses, the whole calling of subclasses can be tedious and involve considerable extra typing. -------------------------------------------- ZE2 intial Namespace design idea. In a namespace/import scenario, which was originally envisioned.. A number of issues occured: - import would never work into a global scope - as it wastes alot of resorces at runtime in PHP, this works on java/c# because they are compile time resolved, so the expensive/complex searching that this requires can be done then.. - the transition of PEAR (the theoritcal prime user) seemed complex and difficult, - eg. the conversion of one to the other looked like being problematic - wildcard importing of namespaces makes code unreadable :) well thats imho :) and would probably be banned in pear anyway :) ------------------------------------------ RFC on a solution One posiblity to solve this is to have Package aliasing, rather than 'real/conventional' namespaces Since the easiest way to explain this is by example.. here they are.... class PEAR:This:is:The:Package { // this aliases " PEAR:This:is:The:Package" as _Package, so when ever the compiler sees _Package:.... in the // code it gets replaced at compile time with PEAR:This:is:The:Package // the _(underscore) prefix on Package is just a convention to prevent it clashing with a 'real' defined package/class. // could be used without (at your own risk...)

    alias  as _Package;
     // note the scope of this alias is only limited to the class it is defined..

// and the replacement is done at compile time only! function someMethod () {

            $me = new __CLASS__;
            $tokenizer = new _Package:someClass();
            // or
            $tval = _Package:someClass::$staticVar;                   $tval = _Package:someClass::anotherMethod()
            // or just use fully resolved
            $tokenizer = new This_is_The_Package:someClass();

} function factory($name) {

         require_once "a/b/c/$name.php";
         // note that strings can not be expanded with the alias........???
         return new 'PEAR:This:is:The:Package:'.$name;

} // and now a subclass of the package - the package name is what would could be called the namespace class PEAR:This:is:The:Package:someClass { // since this could be 1-3 levels down, explicitly detailing the aliais would be required.. alias PEAR:This:is:The:Package as _Package; // this aliases an external package - not encouraged, but usefull when you are // creating alot of new instances of it..

    alias PEAR:HTML:Template as _Template
    alias PEAR:HTML as _HTML

// project based aliasing? alias My:Project:DataObjects as _DO; function anotherMethod() {

         // using the alias to reference one of Flexy's classes
         $s = new _Template:Flexy:Tokenizer();
    }

} While this is not use/import/namespace - it offers a solution to most of the issues faced by PEAR, and I would presume other large scale projects. - It's done at compile time. - hence little to no performance issues - It's minimally scoped.. - only affects methods inside classes. (and possible to pick up clashes at compile time - eg. alias to _XXXx, but _XXXX is already defined as a base package name' - It's not as much work :) - trades off the benifits of wildcard imports against the redability of aliasing. --------------------------------------------- Ok. Fire away........ Regards Alan