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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to