Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17170
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20050707141214.02824ab0@localhost>
Date: Thu, 07 Jul 2005 14:13:35 -0700
To: Jessie Hernandez <jrhernandez05@gmail.com>,internals@lists.php.net
In-Reply-To: <84.75.05285.5EA7CC24@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] YANP (Yet Another Namespace Proposal)
From: andi@zend.com (Andi Gutmans)
References: <84.75.05285.5EA7CC24@pb1.pair.com>

Did you make sure to real all the past threads on the issue?
There are a variety of problems which arise with such a namespaces 
implementation, including ambiguity, problems with multiple symbol table 
lookups, dynamic variable creation, cross-file dependencies. I believe this 
solution suffers from mostly the same problems.

Andi

At 08:44 PM 7/6/2005 -0400, Jessie Hernandez wrote:
>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