Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17333
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 20 Jul 2005 08:36:43 +0200
Reply-To: Marcus Boerger <mail@marcus-boerger.de>
Message-ID: <681697173.20050720083643@marcus-boerger.de>
To: Jessie Hernandez <jrhernandez05@gmail.com>
Cc: internals@lists.php.net
In-Reply-To: <52.31.61486.E8DCDD24@pb1.pair.com>
References: <52.31.61486.E8DCDD24@pb1.pair.com>
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: mail@marcus-boerger.de (Marcus Boerger)

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



-- 
Best regards,
 Marcus                            mailto:mail@marcus-boerger.de