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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
