Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17351
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <9C.92.33635.F0C0FD24@pb1.pair.com>
To: internals@lists.php.net
Date: Wed, 20 Jul 2005 22:44:27 -0400
References: <52.31.61486.E8DCDD24@pb1.pair.com> <681697173.20050720083643@marcus-boerger.de>
Lines: 89
User-Agent: KNode/0.8.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Subject: Re: [PHP-DEV] [PATCH] Namespace Patch, Alpha 3
From: jrhernandez05@gmail.com (Jessie Hernandez)

Hello Marcus! Thanks for the cvs add "hack", worked like a charm! I'll post
an updated patch in a few days.


--
Jessie


Marcus Boerger wrote:

> Hello Jessie,
> 
> Wednesday, July 20, 2005, 6:05:30 AM, you wrote:
> 
>> Private class support has been completed in the attached patch! Again, to
>> reiterate from my last post, the attached patch is a CVS patch, as some
>> requested me to do. I could not add the test files to the patch because
>> "cvs add" failed with a "cvs add requires write access to the repository"
>> error (any way to fix this?).
> 
> You can add the line yourself:
> marcus@zaphod /usr/src/php5 $ cvs add 061.csv
> cvs add: use 'cvs commit' to add this file permanently
> marcus@zaphod /usr/src/php5 $ cat CVS/Entries
> [...]
> /061.csv/0/dummy timestamp//
> 
>> 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.
> 
> Please don't add new ini settings here, living with include_path should be
> enough, wouldn't it?
> 
>> 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. Right now, when an undefined class is found, the __autoload
>> function is called from zend_lookup_class to attempt to declare the class
>> at that point. What I propose is to modify zend_lookup_class to do an
>> additional lookup, either before/after the __autoload function, for
>> namespace imported classes. Here's an example:
> 
>> <?php
>> import namespace my_namespace1;
>> // my_namespace1 is added to a runtime hashtable
>> import namespace my_namespace2;
>> // my_namespace2 is added to a runtime hashtable
> 
>> $a = new class1();
> ?>>
> 
> Why can't __autoload decide itself? I mean either it knows it received a
> namespace class since the string contains a ':' or the function writer
> has to find out himself.
> 
>> At compile-time, the "my_namespace1" and "my_namespace2" strings are
>> saved in a runtime hashtable. At runtime, zend_lookup_class will be
>> called on "class1", as usual. Before/after __autoload, this hashtable
>> will be traversed for the file "class1.php". So in the above example, an
>> attempt to include "$class_path/my_namespace1/class1.php" will be done.
>> If that fails, then my_namespace2 is tried, and so forth. If one of these
>> attempts succeed, then the import alias is also added to the import
>> hashtable for the currently-executed file, as if the user had added
>> "import my_namespace1:class1" to the script.
> 
>> (BTW, is there a way to construct an opcode at runtime and execute it
>> immediately? If not, I'll have to duplicate the code I have for
>> ZEND_IMPORT_CLASS in another function).
> 
> In that case you should provide a function apart the import opcode
> handler. Since zend_vm_gen.h might create multiple handlers out of it this
> is anyway perhaps a good idea. This function can be used of course from
> both handlers and you other function.
> 
>> I think this approach is the easiest and most sensible for namespace
>> import support. It is no more than a specialized "__autoload". If there
>> are no objections, I'll start working on it next week. As always,
>> comments/suggestions are most appreciated.
> 
> 
>> Regards,
> 
>> Jessie Hernandez
> 
> 
>