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):
-
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). -
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
-
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? -
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
""Jessie Hernandez"" jrhernandez05@gmail.com wrote in message
news:FE.F6.14828.BA52F834@pb1.pair.com...
- 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
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...
- 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 ==> ::$Al0t3k
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:
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...
- 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? Theserules
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 ==> ::$Al0t3k
""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
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:
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):
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).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
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?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
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 :::
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