Re: [PHP-DEV] Namespaces in Core

[Sara Golemon]

On Tue, Feb 7, 2017 at 6:59 PM, Dan Ackroyd  wrote:
> On 7 February 2017 at 17:56, Scott Arciszewski  wrote:
>> I'm taking all the No votes spawned by this thread to mean "we
>> don't want namespaced functions ever".
>
> That would be a bad assumption.
>
Confirmed. I'm not against EVER having namespaces, but we need to
decide one way or the other rather than piece-mealing it.

> aka it should be a separate discussion to whether libsodium should be
> included in PHP7.2.
>
+1

-Sara

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

Re: [PHP-DEV] Namespaces in Core

[Dan Ackroyd]

On 7 February 2017 at 17:56, Scott Arciszewski  wrote:
> I'm taking all the No votes spawned by this thread to mean "we
> don't want namespaced functions ever".


That would be a bad assumption.

Peter Cowburn wrote:
> Slinking in a vote which essentially is about adopting
> namespaces in core, via new library RFC, is not the way to go about
> changing our coding standards.  In short, I don't want to the see the
> situation where this extension gets merged in to 7.2 (which it should be
> :)) only to have someone ask, "what about the 'php' top-level namespace?"
> and we all shrug and mutter, "too late" under our breaths.

aka it should be a separate discussion to whether libsodium should be
included in PHP7.2.

cheers
Dan

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

Re: [PHP-DEV] Namespaces in Core

[Scott Arciszewski]

On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder  wrote:

> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
>
> The second vote is clearly going to be that this new feature is added to
> the core with a namespace. I already complained about this but it seems
> to go unnoticed or others do not see the potential problems that might
> be introduced by this.
>
> Sodium (or insert possible future namespace in Core here) might be a
> valid username and existing community standards use the first namespace
> for the vendor. Using those first level vendor namespaces in Core always
> comes a long with a potential problem for users with that name.
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
> Using the PHP vendor name as first level namespace would defeat problems
> with userland namespaces and be a much safer choice. Hence,
> `php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice.
>
> There is another issue regarding auto-loading. If we randomly introduce
> first-level namespaces we de facto make it much harder for us to exclude
> some pattern from the auto-loader. However, putting everything Core
> related into `Php` would mean that we can always sidestep any
> auto-loader calls since we know up front that this must be a C thing.
>
> Most package and/or namespace system do that to avoid problems with
> their users:
>
> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...
>
> Obviously there are some counter examples too:
>
> - Go: random
> - Python: random
> - Javascript: random
> - ...
>
> But at least they go through an extensive standardization process where
> the names are being discussed ad infinitum to ensure that they are super
> generic and thus useful. It is very unlikely that `IO` or `OS` collides
> with a username.
>
> I personally would love to see namespaces but I definitely do not want
> to see random namespaces. I hope we are not going down a road that is
> hard to repair later, like with so many other things we have in Core today.
>
> [1] Rust decided against vendor names for some reasons they explained
> once in a blog post. I believe that this will become a problem for them
> at some point in time since coming up with nice names over time for
> users is very hard. We'll see if Rust persists and invalidates my concerns.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
​Hi,
​

> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...



I​ would definitely like to see something like this land in 7.2:

$plaintext = \Std\Sodium\box_open($ciphertext, $key, $nonce);

Is everyone willing to allow the coding standard to be updated at all,
though? I'm taking all the No votes spawned by this thread to mean "we
don't want namespaced functions ever".

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 
​

Re: [PHP-DEV] Namespaces in Core

[Fleshgrinder]

On 2/7/2017 11:39 AM, Niklas Keller wrote:
> I don't see this as a potential problem. Autoloadeds are (1) not triggered
> for already loaded symbols and (2) and more importantly, autoloaders
> usually use a list of prefixes to load, so a whitelist, not a blacklist.
> 
> Regards, Niklas
> 

This is related to previous discussions about the implementation of
auto-loaders for functions and constants where we it was always a
problem on how to deal with stuff that has no use statement and no
namespace prefix, e.g.:

contains('foo');

In all cases, we know that the auto-loader does not require triggering
because the references are not ambiguous and that is what this was about.

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] Namespaces in Core

[Fleshgrinder]

There will be breaking changes for the sodium users anyways since some
functions will not be included and the complete error handling needs to
be changed from errors to exceptions.

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] Namespaces in Core

[Julien Pauli]

On Tue, Feb 7, 2017 at 12:00 PM, Derick Rethans  wrote:

> On Mon, 6 Feb 2017, Nikita Popov wrote:
>
> > On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder 
> wrote:
> >
> > > First: I like namespaces in Core but here me out!
>
> 
>
> > I'm strongly against use of the PHP namespace as a blanket namespace for
> > bundled PHP extensions. The PHP namespace should be used only for
> > functionality that is actually in some way related to PHP. For example,
> the
> > php-ast extension could reasonably be namespaced as php\ast, as it
> provides
> > an AST for PHP specifically. Similarly the tokenizer extension could
> > reasonably be namespaced as php\tokenizer.
> >
> > Extensions which are not of this type should not live in the PHP
> namespace,
> > because they don't have anything specifically to do with php, apart from
> > the circumstance that they happen to be bundled at the current point in
> > time. Remember that extension may move from being bundled to being in
> PECL
> > and vice versa. If we decide to bundle the MongoDB extension with php,
> > would we rename the currently used MongoDB namespace to PHP\MongoDB? If
> we
> > decided to move it back to PECL, would the namespace go back to just
> > MongoDB? Or would it stay PHP\MongoDB, despite not being part of PHP
> > anymore? Should all new extensions be written with a PHP namespace to
> > account for the possibility of the extension being bundled with PHP at a
> > later point in time (even if there are no concrete plans to do so)?
> >
> > I would answer No to these questions. The namespace MongoDB is not, as
> you
> > say, "random", it is *meaningful*. The namespace PHP is (with the
> > exceptions in the first paragraph notwithstanding) meaningless and an
> > artifact of the distribution mechanism, a mechanism which may change over
> > time.
>
> I very much agree with all of this, and would like to add, that for a
> *long* time it has been documented that PHP owns the top-level
> namespace:
> http://php.net/manual/en/userlandnaming.rules.php
>
> In any case, a discussion to namespace any existing PHP functionality
> should really wait until PHP 8 - and that means, that if we decide to
> put Sodium in PHP 7.x, it should not be namespaced out of consistenct
> *no matter what the RFC result* says.
>
>

I tend to agree with that.

Every move its time.

Namespacing PHP functions must wait for PHP 8.

But with those ideas, there is a dilema : we are going to break PECL/Sodium
users, as they now use namespaces (via PECL ext)
and would need to use functions tomorrow, to use back again namespaces
probably in several years 
Sounds not too good neither :-p


Julien.Pauli

Re: [PHP-DEV] Namespaces in Core

[Derick Rethans]

On Mon, 6 Feb 2017, Stanislav Malyshev wrote:

> > I'm strongly against use of the PHP namespace as a blanket namespace 
> > for bundled PHP extensions. The PHP namespace should be used only 
> > for functionality that is actually in some way related to PHP. For 
> > example, the php-ast extension could reasonably be namespaced as 
> > php\ast, as it provides an AST for PHP specifically. Similarly the 
> > tokenizer extension could reasonably be namespaced as php\tokenizer.
> 
> Agree. If we ever need namespace for mongodb extension, it should be 
> mongodb (choose capitalization to your liking), not php\mongodb - php\ 
> should be things that are really php core or specifically deal with 
> aspects of php as a language - tokenizer, syntax, etc.

It already has the MongoDB namespace btw:
http://php.net/manual/en/book.mongodb.php

And I would say that I would not agree with that namespace changing 
to (nothing) *if* it would be part of the PHP core distribution, instead 
I would choose for it to not be part of the core PHP distribution to 
avoid breaking BC.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Namespaces in Core

[Derick Rethans]

On Mon, 6 Feb 2017, Sara Golemon wrote:

> On Mon, Feb 6, 2017 at 3:47 PM, Nikita Popov  wrote:
>
> > I'm strongly against use of the PHP namespace as a blanket namespace 
> > for bundled PHP extensions. The PHP namespace should be used only 
> > for functionality that is actually in some way related to PHP. For 
> > example, the php-ast extension could reasonably be namespaced as 
> > php\ast, as it provides an AST for PHP specifically. Similarly the 
> > tokenizer extension could reasonably be namespaced as php\tokenizer.
> >
> Okay, I'm pickin' up what yer layin' down.  Perhaps the question then 
> should be asked in the other direction:
> 
> Given PHP's long history and fanatical dedication to BC, should all 
> bundled/core classes/functions/constants ALWAYS remain in the root 
> namespace with a strong advisory to userspace libraries and 
> applications to use vendor namespacing (which by and large, is 
> precisely the status quo).

That would be my preference.

> If that makes sense, then that's another reason not to bring Sodium in 
> as a namespaced library of functions.

Exactly my conclusion :-)

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug

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

Re: [PHP-DEV] Namespaces in Core

[Derick Rethans]

On Mon, 6 Feb 2017, Nikita Popov wrote:

> On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder  wrote:
> 
> > First: I like namespaces in Core but here me out!



> I'm strongly against use of the PHP namespace as a blanket namespace for
> bundled PHP extensions. The PHP namespace should be used only for
> functionality that is actually in some way related to PHP. For example, the
> php-ast extension could reasonably be namespaced as php\ast, as it provides
> an AST for PHP specifically. Similarly the tokenizer extension could
> reasonably be namespaced as php\tokenizer.
> 
> Extensions which are not of this type should not live in the PHP namespace,
> because they don't have anything specifically to do with php, apart from
> the circumstance that they happen to be bundled at the current point in
> time. Remember that extension may move from being bundled to being in PECL
> and vice versa. If we decide to bundle the MongoDB extension with php,
> would we rename the currently used MongoDB namespace to PHP\MongoDB? If we
> decided to move it back to PECL, would the namespace go back to just
> MongoDB? Or would it stay PHP\MongoDB, despite not being part of PHP
> anymore? Should all new extensions be written with a PHP namespace to
> account for the possibility of the extension being bundled with PHP at a
> later point in time (even if there are no concrete plans to do so)?
> 
> I would answer No to these questions. The namespace MongoDB is not, as you
> say, "random", it is *meaningful*. The namespace PHP is (with the
> exceptions in the first paragraph notwithstanding) meaningless and an
> artifact of the distribution mechanism, a mechanism which may change over
> time.

I very much agree with all of this, and would like to add, that for a 
*long* time it has been documented that PHP owns the top-level 
namespace:
http://php.net/manual/en/userlandnaming.rules.php

In any case, a discussion to namespace any existing PHP functionality 
should really wait until PHP 8 - and that means, that if we decide to 
put Sodium in PHP 7.x, it should not be namespaced out of consistenct 
*no matter what the RFC result* says.

cheers,
Derick

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

Re: [PHP-DEV] Namespaces in Core

[Niklas Keller]

>
> I thought about this too. I hope you understood that the main reasoning
> for me to choose a well known namespace prefix is related to
> auto-loading and when to trigger it. The lack of function and constant
> auto-loading is a pain and having well known prefixes could solve the
> issue since we would never require to even look at the auto-loader if
> the namespace starts with php.
>
> Obviously this could be solved for C extensions by allowing them to
> register another prefix that should not be auto-loaded: Sodium, MongoDB,
> ...
>
> Another solution could be to use pecl as their prefix. Although this
> couples it to the packaging system which might not be so nice.
>
> Any name that is tied to a company name or something else that makes
> things impossible for users to claim (Oracle, MongoDB, ...) is not a
> problem. In case of sodium that would probably be Paragon but Sodium
> might be fine too.
>
> I am not the judge here, the only thing I want is to ensure that this
> does not go unseen and that the potential of breaking something is real
> if we choose a random route like some others do. Not saying that we
> cannot do it, big ecosystems live without problems doing the same.
> However, it should be a very conscious choice and none that is taken
> lightly: meaning rules!


I don't see this as a potential problem. Autoloadeds are (1) not triggered
for already loaded symbols and (2) and more importantly, autoloaders
usually use a list of prefixes to load, so a whitelist, not a blacklist.

Regards, Niklas

Re: [PHP-DEV] Namespaces in Core

[Tony Marston]

"Stanislav Malyshev"  wrote in message 
news:a8d24d41-bd3a-0881-3fcb-9366fe974...@gmail.com...


Hi!


New classes within 7.2 (e.g. \HashContext) to be moved without concern
for BC (e.g. \php\Hash\HashContext)

Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)


Do we really need this? I mean, it's not very likely that there's
another RecursiveIteratorIterator in PHP code, and in user code it'd be
namespaced anyway... It just looks like a lot of moving things around
without any visible (at least visible to me) benefit. And given that no
code would be able to use the long name for like 10 years, and even then
why would anybody use long name if short one works In general, I
don't see a point. New exts/features - sure.


I agree with Stanislav. Everyone should remember that namespaces were only 
invented to deal with a particular problem - that of name collisions with 
user-land code or third-party libraries. It was NEVER intended to be applied 
to all core functions. Do you realise that this will break ALL existing 
code? For what benefit? Just to satisfy someone's personal preference is NOT 
enough justification.


--
Tony Marston


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

Re: [PHP-DEV] Namespaces in Core

[Tony Marston]

"Fleshgrinder"  wrote in message 
news:04295b76-3e0d-5ea3-7b4e-d07a15db4...@fleshgrinder.com...


On 2/6/2017 9:47 PM, Nikita Popov wrote:

I'm strongly against use of the PHP namespace as a blanket namespace
 for bundled PHP extensions. The PHP namespace should be used only
for functionality that is actually in some way related to PHP. For
example, the php-ast extension could reasonably be namespaced as
php\ast, as it provides an AST for PHP specifically. Similarly the
tokenizer extension could reasonably be namespaced as php\tokenizer.

Extensions which are not of this type should not live in the PHP
namespace, because they don't have anything specifically to do with
php, apart from the circumstance that they happen to be bundled at
the current point in time. Remember that extension may move from
being bundled to being in PECL and vice versa. If we decide to bundle
the MongoDB extension with php, would we rename the currently used
MongoDB namespace to PHP\MongoDB? If we decided to move it back to
PECL, would the namespace go back to just MongoDB? Or would it stay
PHP\MongoDB, despite not being part of PHP anymore? Should all new
extensions be written with a PHP namespace to account for the
possibility of the extension being bundled with PHP at a later point
 in time (even if there are no concrete plans to do so)?

I would answer No to these questions. The namespace MongoDB is not,
as you say, "random", it is *meaningful*. The namespace PHP is (with
 the exceptions in the first paragraph notwithstanding) meaningless
and an artifact of the distribution mechanism, a mechanism which may
 change over time.

Regards, Nikita



I thought about this too. I hope you understood that the main reasoning
for me to choose a well known namespace prefix is related to
auto-loading and when to trigger it. The lack of function and constant
auto-loading is a pain


Not to me, it isn't! I have been using PHP since 2002 and I have never had 
an issue with this. Perhaps this is because I don't have weird development 
practices.



and having well known prefixes could solve the
issue since we would never require to even look at the auto-loader if
the namespace starts with php.

Obviously this could be solved for C extensions by allowing them to
register another prefix that should not be auto-loaded: Sodium, MongoDB, 
...


Another solution could be to use pecl as their prefix. Although this
couples it to the packaging system which might not be so nice.

Any name that is tied to a company name or something else that makes
things impossible for users to claim (Oracle, MongoDB, ...) is not a
problem. In case of sodium that would probably be Paragon but Sodium
might be fine too.

I am not the judge here, the only thing I want is to ensure that this
does not go unseen and that the potential of breaking something is real
if we choose a random route like some others do. Not saying that we
cannot do it, big ecosystems live without problems doing the same.
However, it should be a very conscious choice and none that is taken
lightly: meaning rules!



Introducing a new rule which breaks code that has been running happily for 
the past 15 years sounds like a bad idea to me. VERY bad.


--
Tony Marston


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

Re: [PHP-DEV] Namespaces in Core

[Lester Caine]

On 07/02/17 08:53, Rowan Collins wrote:
>> I think the Sodium RFC vote is not about namespace but rather about
>> breaking everything which already use the pecl extension.
> Well, it's about both, that's why it's a hard question: in order not to break 
> existing use of the extension, we need to break existing conventions by 
> adding a namespace to core.
> 
> I agree with Richard that this should be decided as a general policy, rather 
> than a special exemption for this one extension, and then a fresh debate next 
> time, and next...

Once again it's about the distribution process rather than anything
fundamental to how php works? The 'linux' project PHP package is
probably the only distribution that 'bundles' a set of extensions in the
one package, as even the windows package allows individual extension
selection. Does any linux distribution actually use the php
'convention'? They all allow a different basic bundle using different
styles of control and manage all of the extensions separately.

The rfc is ... I want libsodium available on all php distributions!
That is simply not going to happen, and those distributions which have
already added namespace will follow one path, while the others will
continue to offer the current package as a 'non-namespaced' addition to
their core install as any other optional extension.

There should be a list of core functionality which everyone can 'rely'
on, and libsodium may have a place in that list, but equally users need
to be aware that it may not be present and act accordingly.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Namespaces in Core

[Rasmus Schultz]

Just my two cents, but moving and aliasing core PHP
classes/interfaces/functions sounds like an absolutely horrible idea.

My biggest question is WHY would you do that?

Writing user-space code today that uses the global namespace would be
considered extremely bad practice - no one should do that.

If you move everything from the root namespace into new namespaces, what
will that accomplish? You'll have an empty root namespace. But for what?

If nobody else is using the root namespace for anything, how is it
problematic for the language itself to do that?

Besides, it'll be a decade before you can actually remove the root
namespace aliases.

I don't see the point of changing this, at all.

It will lead to inconsistent code and a lot of meaningless overhead for
developers - who, ultimately, stand to gain nothing from this change.


On Mon, Feb 6, 2017 at 9:27 PM, Sara Golemon  wrote:

> On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder 
> wrote:
> > First: I like namespaces in Core but here me out!
> >
> > The PHP (case does not matter) would be the proper vendor name to put
> > Core stuff in, as far as I remember it is also reserved for PHP
> > functionality. There were also numerous discussions about providing a
> > cleaned up API there while maintaining backwards compatibility via
> > aliases and so forth in the non-namespaced Core stuff.
> >
> I've been having this same thought lately since looking at the sodium
> RFC.  Here are my thoughts, centered on the goal of having classes
> (and maybe functions?) in a \php\{extname}\ namespace hierarchy.
>
> New classes within 7.2 (e.g. \HashContext) to be moved without concern
> for BC (e.g. \php\Hash\HashContext)
>
> Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
> ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)
>
> "Aliasing" could be potentially accomplished in a few ways:
> 1. Literally just class_alias().  Put another copy of the
> zend_class_entry into the EG(class_table) under a different name.
> 2. "Auto-use": Compile-time analysis of classname: "Is it in this list
> of BC classes? Implicitly map it."
> 3. ...?
>
> I like #2 because we can raise compile-time deprecation warnings and
> we don't introduce any runtime overhead for most cases.
>
> Obviously, no removal of support for non-namespaced names until AT LEAST
> PHP 8.0
>
> This two big unanswered questions for me before I'd put this into an RFC
> are:
> 1. How to achieve BC in the best way
> 2. What to do about functions/constants? Instinct says move 'em just
> like classes.
>
> -Sara
>
> P.S. - wrt libsodium, I think THIS issue is enough for me to come down
> on the side of voting non-namespaced to avoid it being an odd-duck.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Namespaces in Core

[Rowan Collins]

On 7 February 2017 06:52:32 GMT+00:00, Remi Collet  
wrote:
>> https://wiki.php.net/rfc/libsodium
>
>I think the Sodium RFC vote is not about namespace but rather about
>breaking everything which already use the pecl extension.

Well, it's about both, that's why it's a hard question: in order not to break 
existing use of the extension, we need to break existing conventions by adding 
a namespace to core.

I agree with Richard that this should be decided as a general policy, rather 
than a special exemption for this one extension, and then a fresh debate next 
time, and next...

Regards,

-- 
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] Namespaces in Core

[Remi Collet]

Le 06/02/2017 à 18:21, Fleshgrinder a écrit :
> Hey guys! :)
> 
> First: I like namespaces in Core but here me out!
> 
> https://wiki.php.net/rfc/libsodium

I think the Sodium RFC vote is not about namespace but rather about
breaking everything which already use the pecl extension.

This extension exists for some time now,
and I don't think we have to break it.



Remi.




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Namespaces in Core

[Stanislav Malyshev]

Hi!

> New classes within 7.2 (e.g. \HashContext) to be moved without concern
> for BC (e.g. \php\Hash\HashContext)
> 
> Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
> ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)

Do we really need this? I mean, it's not very likely that there's
another RecursiveIteratorIterator in PHP code, and in user code it'd be
namespaced anyway... It just looks like a lot of moving things around
without any visible (at least visible to me) benefit. And given that no
code would be able to use the long name for like 10 years, and even then
why would anybody use long name if short one works In general, I
don't see a point. New exts/features - sure.

> "Aliasing" could be potentially accomplished in a few ways:
> 1. Literally just class_alias().  Put another copy of the
> zend_class_entry into the EG(class_table) under a different name.
> 2. "Auto-use": Compile-time analysis of classname: "Is it in this list
> of BC classes? Implicitly map it."
> 3. ...?
> 
> I like #2 because we can raise compile-time deprecation warnings and
> we don't introduce any runtime overhead for most cases.
> 
> Obviously, no removal of support for non-namespaced names until AT LEAST PHP 
> 8.0
> 
> This two big unanswered questions for me before I'd put this into an RFC are:
> 1. How to achieve BC in the best way
> 2. What to do about functions/constants? Instinct says move 'em just
> like classes.

I don't really want \PHP\Core\Constants\E_NOTICE. This looks like
annoying parts of Java too much. I mean, namespaces are great, I use
them every day, they are super-helpful - but that doesn't mean we should
put everything in deep namespaces - especially things that are already
quite fine without them.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Namespaces in Core

[Stanislav Malyshev]

Hi!

> I'm strongly against use of the PHP namespace as a blanket namespace for
> bundled PHP extensions. The PHP namespace should be used only for
> functionality that is actually in some way related to PHP. For example, the
> php-ast extension could reasonably be namespaced as php\ast, as it provides
> an AST for PHP specifically. Similarly the tokenizer extension could
> reasonably be namespaced as php\tokenizer.

Agree. If we ever need namespace for mongodb extension, it should be
mongodb (choose capitalization to your liking), not php\mongodb - php\
should be things that are really php core or specifically deal with
aspects of php as a language - tokenizer, syntax, etc.

And having different NS for extensions in core vs. PECL makes no sense
to me either - especially given that for any user of distros this
distinction is completely immaterial.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Namespaces in Core

[Sara Golemon]

On Mon, Feb 6, 2017 at 3:47 PM, Nikita Popov  wrote:
> I'm strongly against use of the PHP namespace as a blanket namespace for
> bundled PHP extensions. The PHP namespace should be used only for
> functionality that is actually in some way related to PHP. For example, the
> php-ast extension could reasonably be namespaced as php\ast, as it provides
> an AST for PHP specifically. Similarly the tokenizer extension could
> reasonably be namespaced as php\tokenizer.
>
Okay, I'm pickin' up what yer layin' down.  Perhaps the question then
should be asked in the other direction:

Given PHP's long history and fanatical dedication to BC, should all
bundled/core classes/functions/constants ALWAYS remain in the root
namespace with a strong advisory to userspace libraries and
applications to use vendor namespacing (which by and large, is
precisely the status quo).

If that makes sense, then that's another reason not to bring Sodium in
as a namespaced library of functions.

-Sara

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

Re: [PHP-DEV] Namespaces in Core

[Michał Brzuchalski]

Idea with PHP prefix is quite interesting, but as Nikita said only for PHP
related features.
There is one missing thing in those proposals.
Let's make PHP great again! Let it be `PHP\` prefix :)
To be camel or not to be? - solved!

2017-02-06 22:01 GMT+01:00 Fleshgrinder :

> On 2/6/2017 9:47 PM, Nikita Popov wrote:
> > I'm strongly against use of the PHP namespace as a blanket namespace
> >  for bundled PHP extensions. The PHP namespace should be used only
> > for functionality that is actually in some way related to PHP. For
> > example, the php-ast extension could reasonably be namespaced as
> > php\ast, as it provides an AST for PHP specifically. Similarly the
> > tokenizer extension could reasonably be namespaced as php\tokenizer.
> >
> > Extensions which are not of this type should not live in the PHP
> > namespace, because they don't have anything specifically to do with
> > php, apart from the circumstance that they happen to be bundled at
> > the current point in time. Remember that extension may move from
> > being bundled to being in PECL and vice versa. If we decide to bundle
> > the MongoDB extension with php, would we rename the currently used
> > MongoDB namespace to PHP\MongoDB? If we decided to move it back to
> > PECL, would the namespace go back to just MongoDB? Or would it stay
> > PHP\MongoDB, despite not being part of PHP anymore? Should all new
> > extensions be written with a PHP namespace to account for the
> > possibility of the extension being bundled with PHP at a later point
> >  in time (even if there are no concrete plans to do so)?
> >
> > I would answer No to these questions. The namespace MongoDB is not,
> > as you say, "random", it is *meaningful*. The namespace PHP is (with
> >  the exceptions in the first paragraph notwithstanding) meaningless
> > and an artifact of the distribution mechanism, a mechanism which may
> >  change over time.
> >
> > Regards, Nikita
> >
>
> I thought about this too. I hope you understood that the main reasoning
> for me to choose a well known namespace prefix is related to
> auto-loading and when to trigger it. The lack of function and constant
> auto-loading is a pain and having well known prefixes could solve the
> issue since we would never require to even look at the auto-loader if
> the namespace starts with php.
>
> Obviously this could be solved for C extensions by allowing them to
> register another prefix that should not be auto-loaded: Sodium, MongoDB,
> ...
>
> Another solution could be to use pecl as their prefix. Although this
> couples it to the packaging system which might not be so nice.
>
> Any name that is tied to a company name or something else that makes
> things impossible for users to claim (Oracle, MongoDB, ...) is not a
> problem. In case of sodium that would probably be Paragon but Sodium
> might be fine too.
>
> I am not the judge here, the only thing I want is to ensure that this
> does not go unseen and that the potential of breaking something is real
> if we choose a random route like some others do. Not saying that we
> cannot do it, big ecosystems live without problems doing the same.
> However, it should be a very conscious choice and none that is taken
> lightly: meaning rules!
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
regards / pozdrawiam,
--
Michał Brzuchalski
about.me/brzuchal
brzuchalski.com

Re: [PHP-DEV] Namespaces in Core

[Fleshgrinder]

On 2/6/2017 9:47 PM, Nikita Popov wrote:
> I'm strongly against use of the PHP namespace as a blanket namespace
>  for bundled PHP extensions. The PHP namespace should be used only
> for functionality that is actually in some way related to PHP. For 
> example, the php-ast extension could reasonably be namespaced as 
> php\ast, as it provides an AST for PHP specifically. Similarly the 
> tokenizer extension could reasonably be namespaced as php\tokenizer.
> 
> Extensions which are not of this type should not live in the PHP 
> namespace, because they don't have anything specifically to do with 
> php, apart from the circumstance that they happen to be bundled at 
> the current point in time. Remember that extension may move from 
> being bundled to being in PECL and vice versa. If we decide to bundle
> the MongoDB extension with php, would we rename the currently used
> MongoDB namespace to PHP\MongoDB? If we decided to move it back to
> PECL, would the namespace go back to just MongoDB? Or would it stay
> PHP\MongoDB, despite not being part of PHP anymore? Should all new
> extensions be written with a PHP namespace to account for the 
> possibility of the extension being bundled with PHP at a later point
>  in time (even if there are no concrete plans to do so)?
> 
> I would answer No to these questions. The namespace MongoDB is not, 
> as you say, "random", it is *meaningful*. The namespace PHP is (with
>  the exceptions in the first paragraph notwithstanding) meaningless 
> and an artifact of the distribution mechanism, a mechanism which may
>  change over time.
> 
> Regards, Nikita
> 

I thought about this too. I hope you understood that the main reasoning
for me to choose a well known namespace prefix is related to
auto-loading and when to trigger it. The lack of function and constant
auto-loading is a pain and having well known prefixes could solve the
issue since we would never require to even look at the auto-loader if
the namespace starts with php.

Obviously this could be solved for C extensions by allowing them to
register another prefix that should not be auto-loaded: Sodium, MongoDB, ...

Another solution could be to use pecl as their prefix. Although this
couples it to the packaging system which might not be so nice.

Any name that is tied to a company name or something else that makes
things impossible for users to claim (Oracle, MongoDB, ...) is not a
problem. In case of sodium that would probably be Paragon but Sodium
might be fine too.

I am not the judge here, the only thing I want is to ensure that this
does not go unseen and that the potential of breaking something is real
if we choose a random route like some others do. Not saying that we
cannot do it, big ecosystems live without problems doing the same.
However, it should be a very conscious choice and none that is taken
lightly: meaning rules!

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] Namespaces in Core

[Fleshgrinder]

On 2/6/2017 9:27 PM, Sara Golemon wrote:
> I've been having this same thought lately since looking at the sodium
> RFC.  Here are my thoughts, centered on the goal of having classes
> (and maybe functions?) in a \php\{extname}\ namespace hierarchy.
> 
> New classes within 7.2 (e.g. \HashContext) to be moved without 
> concern for BC (e.g. \php\Hash\HashContext)
> 
> Older classes (e.g. \RecursiveIteratorIterator) to be moved AND 
> ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)
> 
> "Aliasing" could be potentially accomplished in a few ways: 1. 
> Literally just class_alias().  Put another copy of the 
> zend_class_entry into the EG(class_table) under a different name. 2. 
> "Auto-use": Compile-time analysis of classname: "Is it in this list 
> of BC classes? Implicitly map it." 3. ...?
> 
> I like #2 because we can raise compile-time deprecation warnings and
>  we don't introduce any runtime overhead for most cases.
> 
> Obviously, no removal of support for non-namespaced names until AT 
> LEAST PHP 8.0
> 
> This two big unanswered questions for me before I'd put this into an 
> RFC are: 1. How to achieve BC in the best way 2. What to do about 
> functions/constants? Instinct says move 'em just like classes.
> 
> -Sara
> 
> P.S. - wrt libsodium, I think THIS issue is enough for me to come 
> down on the side of voting non-namespaced to avoid it being an 
> odd-duck.
> 

0. Discuss what kind of casing we would like to have. The community has
pretty much settled with CamelCase, however, no need to us to adopt
that. Having `Php` is weird but mixing `php\SPL` is weird too. ;)

Most languages simply use lowercase in their namespace and CamelCase for
class names, e.g.:

php\Integer
php\String
php\Utf8String
php\io\Path
php\io\File
php\io\Directory
php\intl\Locale
php\time\DateTime
php\spl\iterators\RecursiveIteratorIterator

Obviously the same is possible with other rules:

PHP\Integer
PHP\String
PHP\UTF8String
PHP\IO\Path
PHP\IO\File
PHP\IO\Directory
PHP\Intl\Locale
PHP\Time\DateTime
PHP\SPL\Iterators\RecursiveIteratorIterator

I really don't care but lets create a sane standard that is easy to
follow. Let's do this right if at all!

I would start emitting deprecations is PHP 8 and consider removal in PHP
9 only after having a close look at the community how they adopt these
changes.

I would not simply move everything. I would consider every API and try
to clean it up before moving it to namespaces. This is a HUGE junk of
work but unlike PHP 6 and UTF-8 it could be done incrementally without
any concerns about BC or anything. Obviously any API that is considered
fine can be moved and aliased.

This would also be the perfect moment to get nikic's scalar object stuff
in (already illustrated in the example list above). There are many other
things in the pipelines that could help us creating a better Core for
the community, specifically Generics and Enums.

Potential is endless but requires very good planning and alignment and
not a secondary vote due to PECL BC concerns.

On 2/6/2017 9:29 PM, Paul Jones wrote:
> I would not have noted this if you had not said something. Thank you 
> for doing so.
> 

I had this fear and expressed it in the libsodium RFC discussion as
well. That is why I created this discussion. This is an epic decision
for the PHP ecosystem and cannot go unnoticed.

I actually would block that second vote to be honest.

-- 
Richard "Fleshgrinder" Fussenegger

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

Re: [PHP-DEV] Namespaces in Core

[Nikita Popov]

On Mon, Feb 6, 2017 at 6:21 PM, Fleshgrinder  wrote:

> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
>
> The second vote is clearly going to be that this new feature is added to
> the core with a namespace. I already complained about this but it seems
> to go unnoticed or others do not see the potential problems that might
> be introduced by this.
>
> Sodium (or insert possible future namespace in Core here) might be a
> valid username and existing community standards use the first namespace
> for the vendor. Using those first level vendor namespaces in Core always
> comes a long with a potential problem for users with that name.
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
> Using the PHP vendor name as first level namespace would defeat problems
> with userland namespaces and be a much safer choice. Hence,
> `php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice.
>
> There is another issue regarding auto-loading. If we randomly introduce
> first-level namespaces we de facto make it much harder for us to exclude
> some pattern from the auto-loader. However, putting everything Core
> related into `Php` would mean that we can always sidestep any
> auto-loader calls since we know up front that this must be a C thing.
>
> Most package and/or namespace system do that to avoid problems with
> their users:
>
> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...
>
> Obviously there are some counter examples too:
>
> - Go: random
> - Python: random
> - Javascript: random
> - ...
>
> But at least they go through an extensive standardization process where
> the names are being discussed ad infinitum to ensure that they are super
> generic and thus useful. It is very unlikely that `IO` or `OS` collides
> with a username.
>
> I personally would love to see namespaces but I definitely do not want
> to see random namespaces. I hope we are not going down a road that is
> hard to repair later, like with so many other things we have in Core today.
>
> [1] Rust decided against vendor names for some reasons they explained
> once in a blog post. I believe that this will become a problem for them
> at some point in time since coming up with nice names over time for
> users is very hard. We'll see if Rust persists and invalidates my concerns.
>

I'm strongly against use of the PHP namespace as a blanket namespace for
bundled PHP extensions. The PHP namespace should be used only for
functionality that is actually in some way related to PHP. For example, the
php-ast extension could reasonably be namespaced as php\ast, as it provides
an AST for PHP specifically. Similarly the tokenizer extension could
reasonably be namespaced as php\tokenizer.

Extensions which are not of this type should not live in the PHP namespace,
because they don't have anything specifically to do with php, apart from
the circumstance that they happen to be bundled at the current point in
time. Remember that extension may move from being bundled to being in PECL
and vice versa. If we decide to bundle the MongoDB extension with php,
would we rename the currently used MongoDB namespace to PHP\MongoDB? If we
decided to move it back to PECL, would the namespace go back to just
MongoDB? Or would it stay PHP\MongoDB, despite not being part of PHP
anymore? Should all new extensions be written with a PHP namespace to
account for the possibility of the extension being bundled with PHP at a
later point in time (even if there are no concrete plans to do so)?

I would answer No to these questions. The namespace MongoDB is not, as you
say, "random", it is *meaningful*. The namespace PHP is (with the
exceptions in the first paragraph notwithstanding) meaningless and an
artifact of the distribution mechanism, a mechanism which may change over
time.

Regards,
Nikita

Re: [PHP-DEV] Namespaces in Core

[Paul Jones]

> On Feb 6, 2017, at 13:50, Peter Cowburn  wrote:
> 
> a vote which essentially is about adopting
> namespaces in core, via new library RFC, is not the way to go about
> changing our coding standards.  In short, I don't want to the see the
> situation where this extension gets merged in to 7.2 (which it should be
> :)) only to have someone ask, "what about the 'php' top-level namespace?"
> and we all shrug and mutter, "too late" under our breaths.

I would not have noted this if you had not said something. Thank you for doing 
so.


-- 
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




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

Re: [PHP-DEV] Namespaces in Core

[Sara Golemon]

On Mon, Feb 6, 2017 at 12:21 PM, Fleshgrinder  wrote:
> First: I like namespaces in Core but here me out!
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
I've been having this same thought lately since looking at the sodium
RFC.  Here are my thoughts, centered on the goal of having classes
(and maybe functions?) in a \php\{extname}\ namespace hierarchy.

New classes within 7.2 (e.g. \HashContext) to be moved without concern
for BC (e.g. \php\Hash\HashContext)

Older classes (e.g. \RecursiveIteratorIterator) to be moved AND
ALIASED FOR BC (e.g. \php\SPL\Iterator\RecursiveIteratorIterator)

"Aliasing" could be potentially accomplished in a few ways:
1. Literally just class_alias().  Put another copy of the
zend_class_entry into the EG(class_table) under a different name.
2. "Auto-use": Compile-time analysis of classname: "Is it in this list
of BC classes? Implicitly map it."
3. ...?

I like #2 because we can raise compile-time deprecation warnings and
we don't introduce any runtime overhead for most cases.

Obviously, no removal of support for non-namespaced names until AT LEAST PHP 8.0

This two big unanswered questions for me before I'd put this into an RFC are:
1. How to achieve BC in the best way
2. What to do about functions/constants? Instinct says move 'em just
like classes.

-Sara

P.S. - wrt libsodium, I think THIS issue is enough for me to come down
on the side of voting non-namespaced to avoid it being an odd-duck.

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

Re: [PHP-DEV] Namespaces in Core

[Peter Cowburn]

On 6 February 2017 at 17:21, Fleshgrinder  wrote:

> Hey guys! :)
>
> First: I like namespaces in Core but here me out!
>
> https://wiki.php.net/rfc/libsodium
>
> The second vote is clearly going to be that this new feature is added to
> the core with a namespace. I already complained about this but it seems
> to go unnoticed or others do not see the potential problems that might
> be introduced by this.
>

I don't often chime in on the internals list, so please excuse this
interruption.  Slinking in a vote which essentially is about adopting
namespaces in core, via new library RFC, is not the way to go about
changing our coding standards.  In short, I don't want to the see the
situation where this extension gets merged in to 7.2 (which it should be
:)) only to have someone ask, "what about the 'php' top-level namespace?"
and we all shrug and mutter, "too late" under our breaths.


>
> Sodium (or insert possible future namespace in Core here) might be a
> valid username and existing community standards use the first namespace
> for the vendor. Using those first level vendor namespaces in Core always
> comes a long with a potential problem for users with that name.
>
> The PHP (case does not matter) would be the proper vendor name to put
> Core stuff in, as far as I remember it is also reserved for PHP
> functionality. There were also numerous discussions about providing a
> cleaned up API there while maintaining backwards compatibility via
> aliases and so forth in the non-namespaced Core stuff.
>
> Using the PHP vendor name as first level namespace would defeat problems
> with userland namespaces and be a much safer choice. Hence,
> `php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice.
>
> There is another issue regarding auto-loading. If we randomly introduce
> first-level namespaces we de facto make it much harder for us to exclude
> some pattern from the auto-loader. However, putting everything Core
> related into `Php` would mean that we can always sidestep any
> auto-loader calls since we know up front that this must be a C thing.
>
> Most package and/or namespace system do that to avoid problems with
> their users:
>
> - Java: `java*`
> - C#: `System*`
> - C++: `::std*`
> - Rust: `core::*` and `std::*` [1]
> - Scala: `scala*`
> - Kotlin: `kotlin*`
> - Ceylon: `ceylon*`
> - ...
>
> Obviously there are some counter examples too:
>
> - Go: random
> - Python: random
> - Javascript: random
> - ...
>
> But at least they go through an extensive standardization process where
> the names are being discussed ad infinitum to ensure that they are super
> generic and thus useful. It is very unlikely that `IO` or `OS` collides
> with a username.
>
> I personally would love to see namespaces but I definitely do not want
> to see random namespaces. I hope we are not going down a road that is
> hard to repair later, like with so many other things we have in Core today.
>
> [1] Rust decided against vendor names for some reasons they explained
> once in a blog post. I believe that this will become a problem for them
> at some point in time since coming up with nice names over time for
> users is very hard. We'll see if Rust persists and invalidates my concerns.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Namespaces in Core

[Fleshgrinder]

Hey guys! :)

First: I like namespaces in Core but here me out!

https://wiki.php.net/rfc/libsodium

The second vote is clearly going to be that this new feature is added to
the core with a namespace. I already complained about this but it seems
to go unnoticed or others do not see the potential problems that might
be introduced by this.

Sodium (or insert possible future namespace in Core here) might be a
valid username and existing community standards use the first namespace
for the vendor. Using those first level vendor namespaces in Core always
comes a long with a potential problem for users with that name.

The PHP (case does not matter) would be the proper vendor name to put
Core stuff in, as far as I remember it is also reserved for PHP
functionality. There were also numerous discussions about providing a
cleaned up API there while maintaining backwards compatibility via
aliases and so forth in the non-namespaced Core stuff.

Using the PHP vendor name as first level namespace would defeat problems
with userland namespaces and be a much safer choice. Hence,
`php\sodium`/`PHP\Sodium`/`Php\Sodium` would be the clear choice.

There is another issue regarding auto-loading. If we randomly introduce
first-level namespaces we de facto make it much harder for us to exclude
some pattern from the auto-loader. However, putting everything Core
related into `Php` would mean that we can always sidestep any
auto-loader calls since we know up front that this must be a C thing.

Most package and/or namespace system do that to avoid problems with
their users:

- Java: `java*`
- C#: `System*`
- C++: `::std*`
- Rust: `core::*` and `std::*` [1]
- Scala: `scala*`
- Kotlin: `kotlin*`
- Ceylon: `ceylon*`
- ...

Obviously there are some counter examples too:

- Go: random
- Python: random
- Javascript: random
- ...

But at least they go through an extensive standardization process where
the names are being discussed ad infinitum to ensure that they are super
generic and thus useful. It is very unlikely that `IO` or `OS` collides
with a username.

I personally would love to see namespaces but I definitely do not want
to see random namespaces. I hope we are not going down a road that is
hard to repair later, like with so many other things we have in Core today.

[1] Rust decided against vendor names for some reasons they explained
once in a blog post. I believe that this will become a problem for them
at some point in time since coming up with nice names over time for
users is very hard. We'll see if Rust persists and invalidates my concerns.

-- 
Richard "Fleshgrinder" Fussenegger

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