Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26523
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Marcus Boerger <helly@php.net>
Message-ID: <45567343.6010305@gmail.com>
Date: Sat, 11 Nov 2006 20:05:07 -0500
User-Agent: Thunderbird 1.5.0.7 (X11/20060913)
MIME-Version: 1.0
References: <4554AE0D.4080600@caedmon.net> <99.20.32592.5ED45554@pb1.pair.com> <19674119.20061111112203@marcus-boerger.de>
In-Reply-To: <19674119.20061111112203@marcus-boerger.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Namespaces in PHP 6 - ++$take
From: jrhernandez05@gmail.com (Jessie Hernandez)

Marcus Boerger wrote:
> Hello Jessie,
> 
[snip]
> 
> Maybe this new discussion gave one hint. Aliases could be solved with a
> flag. Just copy the classwith a new name into the classlist again and flagit
> as copy. Maybe the original class gets a list of the copies of the copies a
> pointer to the original but that would be an implementation detail. As soon
> as that is done importdoes nothingelse then copying classes on a single
> class table. That said namespaces would, if after all, simply contain other
> copies to the original classes. In the extremecase we can start with
> namespaces only being a 'stupid' list. Reflection could then travers all
> classes to see in which namespaces it was registered.
> 
> This btw would also fix 3) as the namespace seperator would be a normal
> sign in class lookup, it would simply be disallowed in definitions of
> class/interface/namespaces.
> 

Did not notice these further comments until now. Anyways, I originally 
implemented imports in this way (making copies in class_table and 
updating the reference count), but then I used another approach because 
then imports would be request-wide, and I wanted them to be 
file-specific only (yeah, I know the PHP6 meeting notes said they should 
be request-wide, but I see this causing many problems to the point where 
they cannot be used in order to guarantee safe code).

Also, yes, ':' are not be allowed in either class or interface 
definitions,  but they are included in the full name in class_table 
(e.g. "namespace_name:class_name"). This is how it is currently in my patch.


Regards,

Jessie Hernandez