Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26522
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <3D.90.24000.85F66554@pb1.pair.com>
To: internals@lists.php.net
Date: Sat, 11 Nov 2006 19:48:22 -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)

Hi Marcus,

As I said, I wanted to only enable classes inside namespaces, and NOT 
allow functions or constants. class::const would stay the same, so there 
are no conflicts.


Marcus Boerger wrote:
> Hello Jessie,
> 
>   sorry to say this but look at the following, keeping in mind that the
> whitespace is optional.
> 
> $x = $foo ? class:const           : $var                    // 1, 0
> $x = $foo ? class:const           : const;                  // 1, 0
> $x = $foo ? class:const           : class:const;            // 1, 1
> $x = $foo ? class:const           : namespace:class:const;  // 1, 2
> $x = $foo ? namespace:class:const : $var;                   // 2, 0
> $x = $foo ? namespace:class:const : const;                  // 2, 0
> $x = $foo ? namespace:class:const : class:const;            // 2, 1
> $x = $foo ? namespace:class:const : namespace:class:const;  // 2, 2
> 
> Feel free to continue that list, it has conflicts whatever you do.
> 
> Saturday, November 11, 2006, 5:13:22 AM, you wrote:
> 
>> Hello,
> 
>> I haven't had time to work on my patch, but thinking about this some 
>> more, I'm convinced namespaces should only contain classes. The only 
>> problem that was present when permitting functions/constants to be 
>> inside namespaces was the ambiguity in ternary expressions. By just 
>> supporting classes inside namespaces, this issue would go away. Besides, 
>> I'll dare say that most, if not all, the developers who want namespaces 
>> will only group classes with it anyways,
> 
>> Also, by only supporting classes, we can use ":" instead of the long 
>> ":::" separator and everyone would be happy.
> 
>> Last I checked, the only things that were pending on my patch were some 
>> scoping issues which I had to fix. These are listed below. Once these 
>> are done, the patch can be formally proposed. If anyone wants to take a 
>> look at the patch so far and/or work on the remaining issues below, let 
>> me know and I'll either post the patch or email it.
> 
> 
>> Pending:
> 
>> 1) The extends clause should resolve imported class names.
> 
>> import class ns:DateBase;
> 
>> namespace ns{ class Date extends DateBase{} }
> 
>> 2) To access a global symbol, use global:<class_name> syntax.
> 
> I would prefer ':::'<class_name> or '\'<class_name> but that doesn't really
> matter as we have 'global' as a keyword already.
> 
>> 3) Type hints should also consider imported classes.
> 
>> 4) When an import is done (with alias or not), and a global class with 
>> that same name exists, what is the desired behavior? Error? Global takes 
>> precedence?
> 
> 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.
> 
> Best regards,
>  Marcus