phpnamespaces.org!

php.internals

Jessie Hernandez

20 years ago
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

l0t3k

20 years ago
""Jessie Hernandez"" <jrhernandez05@gmail.com> wrote in message news:FE.F6.14828.BA52F834@pb1.pair.com...
> > 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:
i should know this, but does PHP use :: as the global scope resolver as in C++ ? if so, namespaced A ==> $A global A ==> ::$A l0t3k

Jessie Hernandez

20 years ago
Hi l0t3k, Yes, this is how it's done in C++, but do we want to allow this syntax for PHP? If so, it'll either be :::A, ::A (can be used, but might be inconsistent as ":::" is used everywhere else), or \A, depending on the final separator... Regards, Jessie ""l0t3k"" <cshmoove@hotmail.com> wrote in message news:E9.1A.14828.54A2F834@pb1.pair.com...
> > ""Jessie Hernandez"" <jrhernandez05@gmail.com> wrote in message > news:FE.F6.14828.BA52F834@pb1.pair.com... > > > > 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: > i should know this, but does PHP use :: as the global scope resolver as
in

M. Sokolewicz

20 years ago
hi, personally, I find :::A, ::A and such constructs *extremely* ugly. Might I suggest using a special keyword to denote global scoped classes? eg: global:::A and such. global already is a keyword, but I'm pretty sure it could be reused in this context. Plus, it clearly shows where you're getting it all from. - tul Jessie Hernandez wrote:

Jessie Hernandez

20 years ago
""M. Sokolewicz"" <tularis@php.net> wrote in message news:438F95BD.2090202@php.net...
> hi, > > personally, I find :::A, ::A and such constructs *extremely* ugly. Might > I suggest using a special keyword to denote global scoped classes? > eg: > global:::A and such. global already is a keyword, but I'm pretty sure it > could be reused in this context. Plus, it clearly shows where you're > getting it all from. >
BRILLIANT! I'm going to take this approach. Thanks!! Regards, Jessie

Marian Kostadinov

20 years ago
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 <jrhernandez05@gmail.com>:

Ron Korving

20 years ago
I assume ::: is being used because it simply works and the discussion on which seperator to use might still go on for some time ;). You have a point about import statements being allowed only in the beginning. This would be nice: class X { public function foo() { import class bar:::MyClass; $obj = new MyClass(); $obj->doSomething(); } } This would be nice, because __autoload() only needs to be called if my method foo() is being called. bar:::MyClass is not a dependency for the whole file, but only for X::foo(). Performance-wise it would be a good thing if importing namespaces would not extend the dependency to the whole file. Also, it could prevent unnecessary aliasing: class X { public function foo() { import class bar:::MyClass; $obj = new MyClass(); $obj->doSomething(); } public function fubar() { import class bla:::MyClass; $obj = new MyClass(); $obj->doSomething(); } } In this example, bar:::MyClass and bla:::MyClass are used. Two different classes, each in their own namespace. Aliasing is not required, because the imported namespaces are limited to the scope of the methods foo() and fubar(). - Ron "Marian Kostadinov" <manchokapitancho@gmail.com> schreef in bericht news:bec76cf90512012309u6e85d2dcg@mail.gmail.com... 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 :::

Jessie Hernandez

20 years ago
Hello Ron, ""Ron Korving"" <r.korving@xit.nl> wrote in message news:8F.C6.14828.4DAFF834@pb1.pair.com...
> I assume ::: is being used because it simply works and the discussion on > which seperator to use might still go on for some time ;). You have a
point
> about import statements being allowed only in the beginning. This would be > nice: > > class X > { > public function foo() > { > import class bar:::MyClass; > $obj = new MyClass(); > $obj->doSomething(); > } > } > > This would be nice, because __autoload() only needs to be called if my > method foo() is being called. bar:::MyClass is not a dependency for the > whole file, but only for X::foo(). Performance-wise it would be a good
thing
> if importing namespaces would not extend the dependency to the whole file. > Also, it could prevent unnecessary aliasing: >
__autoload is not called at the time of import, only when the alias is actually used, so there are actually no performance issues here.
> class X > { > public function foo() > { > import class bar:::MyClass; > $obj = new MyClass(); > $obj->doSomething(); > } > > public function fubar() > { > import class bla:::MyClass; > $obj = new MyClass(); > $obj->doSomething(); > } > } > > In this example, bar:::MyClass and bla:::MyClass are used. Two different > classes, each in their own namespace. Aliasing is not required, because
the
> imported namespaces are limited to the scope of the methods foo() and > fubar(). >
Do we really want this? Since there is no performance improvement having imports be block-scoped, this really is not needed. IMO, it can also create confusion, as the same alias means different things in different contexts of the file. Regards, Jessie