First I must say - a nice job:)
The namespaced version works fine.
I found just 3 problems (things I don't like):

1.Import statements are allowed only in the beginning of the script.
2.Global function calls are not allowed in a namespace.
3.The example below does not work.

<?
import class ABC:::TEST as ABC_TEST;
import function ABC:::FUNC;

namespace ABC {
        class TEST {}
        function FUNC() {
                new TEST;
        }
}
FUNC();
?>

Anyway, the patch seems to be stable.
Also ::: is veeery long. I wrote it a lot of times and usually I got
:: instead of :::



2005/12/1, Jessie Hernandez <[EMAIL PROTECTED]>:
> 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
>
>

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

Reply via email to