Hello Jessie,
we already have consts in our classes, if you look close then you will see
that the table does not conatain 'namespace:const' but only 'namespace:class'
and still there are conflicts already.
best regards
marcus
Sunday, November 12, 2006, 1:48:22 AM, you wrote:
> 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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
