Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] phpnamespaces.org! [RSS Feed]

#1 Dec. 1, 2005 16:33:23

Jessie H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] phpnamespaces.org!


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 visithttp://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

Offline

#2 Dec. 2, 2005 07:11:13

Marian K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] phpnamespaces.org!


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 <>:
> 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 visithttp://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

Offline

#3 Dec. 2, 2005 07:42:42

Ron K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] phpnamespaces.org!


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" <> schreef in bericht

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 :::

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

Offline

#4 Dec. 2, 2005 16:44:41

Jessie H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] phpnamespaces.org!


Hello Ron,

""Ron Korving"" <> wrote in message

> 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

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

Offline

  • Root
  • » PHP
  • » [PHP-DEV] phpnamespaces.org! [RSS Feed]

Board footer

Moderator control

Enjoy the 27th of April
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support