Thanks to several people, the phpnamespaces.org site is up and contains the
latest namespace patch, pre-patched tarballs and Win32 zip, example scripts,
and links to namespace-related news! If you are interested in seeing
namespaces in PHP, or are curious to see the progress of this development,
then please visit http://www.phpnamespaces.org. You are encouraged to join
the mailing list to keep up-to-date and to post any questions/feedback on
the current patch.

Soon a detailed explanation on the internals of the patch will be added
along with documentation for its new features.

The idea for the site was not mine, but several people have contributed
their time, effort, and resources to make this happen. Special thanks goes
out to Hans, Ian, and Tony for obtaining the domain name, server, and adding
the initial content.


Regarding the latest version of the patch, there are several items I'd like
to get feedback on so as to finish the patch (mostly scoping/resolution):

1) Importing of namespace constants (it looks like this was present in one
of the PHP 5.0 betas, so I'm working on adding this).

2) How will symbols be resolved inside namespaces? If a class "A" exists in
namespace "N", and a global class "A" also exists, then by referencing "A",
what should happen? Should the namespaced "A" be used? If so, then the
global "A" cannot be accessed from the namespace. Is this OK? These rules
would need to be the same and affects the following contexts:

- Extends: class B extends A{}
- Type hints for functions/methods inside the namespace
- Method/function bodies inside a namespace

3) If a symbol is imported (having an alias or not) and there is a global
symbol that has that same name, what is the correct behavior? Should the
global symbol be ignored? Should an error occur? Should the global take
precedence?

4) For now the patch uses the ":::" separator. ":" cannot be used, as it
conflicts with the ternary (EVEN if we only leave classes inside namespaces)
and "::" causes ambiguity. The separator is now in a #define, so if worst
comes to worst and ":::" cannot be used/is not desired, then the change to
"\" will be easy.

I'll post any additional issues as I encounter them.


Regards,

Jessie Hernandez

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

Reply via email to