Re: [PHP-DEV] Call it: allow reserved words in a class or not?
What about adding a function that behaves like __autoload, but with
respect to namespace wildcards? Something like:
?php
function __namespace_autoload($namespaceName) {
$dirHandle = opendir(/path/to/app/ . $namespaceName);
while(false !== ($file = readdir($dirHandle))) {
if(substr($file,-3) == php) {
require_once(/path/to/app/ . $namespaceName . / . $file);
}
}
}
?
That would allow for Stan's use foo\bar\* without impacting the
performance of normal __autoload() calls.
Johannes Schlüter wrote:
On Thu, 2008-11-06 at 22:19 -0600, Josh Thompson wrote:
I don't understand why in the namespaced example no one seems to have a
problem with new A() meaning new \foo\bar\A(), but we can't use the *
wildcard to do the same thing?
Since we don't reliable know all possible classes, think about
_-autoloading classes, which means we'd have to do more work during
execution, which can be a slowdown.
johannes
--
Matthew Schiros
President, InvisiHosting.com
Web Development Anonymous Web Host
Security Through Anonymity!
e: [EMAIL PROTECTED]
c: 512-466-4146
f: 888-521-4772
aim: invisirevolution
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hi, This are tentatively looking like alpha3 could hit on November 18th. So everybody please try to get whatever you are working on ready to be finished and committed by no later than 13th. So that packaging can happen on a stable tree on the 17th. Is the output buffering MFH still a lost cause? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
hi! On Fri, Nov 7, 2008 at 9:29 AM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hi, This are tentatively looking like alpha3 could hit on November 18th. So everybody please try to get whatever you are working on ready to be finished and committed by no later than 13th. So that packaging can happen on a stable tree on the 17th. Is the output buffering MFH still a lost cause? I hope not, it is a must have. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On 07.11.2008, at 09:30, Pierre Joye wrote: hi! On Fri, Nov 7, 2008 at 9:29 AM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hi, This are tentatively looking like alpha3 could hit on November 18th. So everybody please try to get whatever you are working on ready to be finished and committed by no later than 13th. So that packaging can happen on a stable tree on the 17th. Is the output buffering MFH still a lost cause? I hope not, it is a must have. To quote myself on this topic: These are all convincing arguments to have done this earlier. But Johannes and I are a bit worried, that this code did not see that much testing since it was checked in to HEAD quite a while ago. And seeing that the backport is mainly cleanup and not bug fixing, we are a bit worried about the risk this backport has (not necessarily in it introducing bugs, but more about BC issues here and there). Especially since it seems that you are the only one who actively looks after output buffering .. (Johannes actually asked to have this stuff in PHP 5.3 months ago, but you were a bit MIA back then .. and nobody else showed interest). So unless you can take our worries away in terms of BC issues, I guess we would prefer to leave this patch out of PHP 5.3. Sorry about the misunderstanding and the work you put into producing this patch. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
hi, On Fri, Nov 7, 2008 at 9:51 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: To quote myself on this topic: These are all convincing arguments to have done this earlier. But Johannes and I are a bit worried, that this code did not see that much testing since it was checked in to HEAD quite a while ago. And seeing that the backport is mainly cleanup and not bug fixing, we are a bit worried about the risk this backport has (not necessarily in it introducing bugs, but more about BC issues here and there). Especially since it seems that you are the only one who actively looks after output buffering .. (Johannes actually asked to have this stuff in PHP 5.3 months ago, but you were a bit MIA back then .. and nobody else showed interest). So unless you can take our worries away in terms of BC issues, I guess we would prefer to leave this patch out of PHP 5.3. Sorry about the misunderstanding and the work you put into producing this patch. It is why alpha releases are for. If we don't merge it we should simply drop it in HEAD and forget it. This code has been there for years now, it is time to bring it to a stable branch. The same applies for other code in HEAD not having merged to 5.3. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
Hi. Steph Fox wrote: This thread really should be re-titled to allow reserved words as a classname or not. Then perhaps the only logical response to the question would be so obvious that there would be no thread... oo-er... Right, the subject indicates a different question that what seems to be discusssed here. The way I understood it was about allowing *methods* named clone in a class. That would come in handy for me, porting interfaces from Java to PHP. Currently I have to go back to klone to make it legal. Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
On Friday 07 November 2008 14:47:59 Josh Thompson wrote: Johannes Schlüter wrote: On Thu, 2008-11-06 at 22:19 -0600, Josh Thompson wrote: I don't understand why in the namespaced example no one seems to have a problem with new A() meaning new \foo\bar\A(), but we can't use the * wildcard to do the same thing? Since we don't reliable know all possible classes, think about _-autoloading classes, which means we'd have to do more work during execution, which can be a slowdown. johannes But we don't reliably know all possible classes in the namespace example, where we can be autoloading the classes. In the wildcard example we (c/w)ould already be autoloading the classes anyway, but instead of sending the class names (A and B) we would send it the namespace class names first (foo\bar\A and foo\bar\B) and then if that failed try without the namespace. If one of the classes (B for example) is in the global namespace, then the developer can simply prefix it with a (\B) to save on one autoload call. I still don't see the fundamental difference between the namespace and wildcard example. using wildcards is considered bad practice in about any language I know, i wonder why people are so anxious to get it into PHP ... anyways, one fundamental difference is that while you can be only in one namespace, you can use from many. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
What about adding a function that behaves like __autoload, but with respect to namespace wildcards? Something like: Hi, Ok so first: 1) We can't implement wildcards since a wildcard needs to be expanded to a set of concrete classes at runtime for it to make sense, and we don't know what those classes are (due to autoloads and conditional require/include constructs). 2) There can't be a method to resolve wildcards, since namespaces currently work 90% at the parse level, before any PHP code has executed. This is required for good performance and simplicity. 3) I have emailed Greg a simple idea for solving this with a INI-like meta namespace file, a simple file we can put in our include path, which describes the resources of a namespace and optionally their location. For example let's say you have namespace My\Name\Space, and inside you have classes Foo, Bar, functions baz and constants ONE, TWO. In one of your include paths, you'll create a file called My.Name.Space.nsmeta and put the following inside: class Foo = path\to\Foo.class.php class Bar = path\to\Bar.class.php function baz = path\to\baz.func.php const ONE = \path\to\constants.php const TWO = \path\to\constants.php This file you can generate from your framework, or even write by hand, as you see it's very simple to write/read, and tokenizes with the existing PHP tokenizer. Since this file will be read at parse time, it has the ability to solve the following problems: 1) zero-performance-impact namespace wildcards (especially with an opcode cache like APC, XCache etc.) 2) faster resource loading (PHP can autoload resources from the location map above without you writing a slow __autoload runtime procedure) 3) you can load on demand now any namespace resources: class, functions, constant, not just classes. Naturally this is not for 5.3 as we all want 5.3 stable and out as soon as possible. But it has the potential to simplify drastically some workflows, especially in large complex frameworks, so if it picks up, maybe 5.4, or 6 or who knows. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
Johannes Schlüter wrote: On Thu, 2008-11-06 at 22:19 -0600, Josh Thompson wrote: I don't understand why in the namespaced example no one seems to have a problem with new A() meaning new \foo\bar\A(), but we can't use the * wildcard to do the same thing? Since we don't reliable know all possible classes, think about _-autoloading classes, which means we'd have to do more work during execution, which can be a slowdown. johannes But we don't reliably know all possible classes in the namespace example, where we can be autoloading the classes. In the wildcard example we (c/w)ould already be autoloading the classes anyway, but instead of sending the class names (A and B) we would send it the namespace class names first (foo\bar\A and foo\bar\B) and then if that failed try without the namespace. If one of the classes (B for example) is in the global namespace, then the developer can simply prefix it with a (\B) to save on one autoload call. I still don't see the fundamental difference between the namespace and wildcard example. -- Joshua Thompson Mechanical Engineer/Software Developer http://www.schmalls.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Case sensitivity
On Nov 6, 2008, at 11:59 PM, Ronald Chmara wrote:
1. All built-in PHP functions should be aliased in the worlds most
used languages, so that declaring a function could also be written
as: funktsioon, otstarve, λειτουργία ,
ویرایش, Fonction, funcionar, fungsi, funzionare,
қызмет, 可算, メソッド, funkcja (etc.)
Can I get a +1?
+1, but it'd be a ++1 if we could also take into consideration
dyslexic programmers. I would like to be able to write:
} (oof$) cnuf_emos noitcnuf
;oof$ ohce
{
/me ducks
-T
P.S. No, I didn't do that programmatically. Lefties have tendencies
towards dyslexia which lets us write both ways without too much
thought :-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Case sensitivity
Travis Swicegood wrote:
On Nov 6, 2008, at 11:59 PM, Ronald Chmara wrote:
1. All built-in PHP functions should be aliased in the worlds most
used languages, so that declaring a function could also be written
as: funktsioon, otstarve, λειτουργία , ویرایش, Fonction,
funcionar, fungsi, funzionare, қызмет, 可算, メソッド,
funkcja (etc.)
Can I get a +1?
+1, but it'd be a ++1 if we could also take into consideration
dyslexic programmers. I would like to be able to write:
} (oof$) cnuf_emos noitcnuf
;oof$ ohce
{
I'd say that's more left-handed than dyslexic. Of course, handling
mistakes in variable names would reduce the number of possibilities
available:
$foo++;
echo $ofo;
if ($oof 4) break;
I am now very tempted to write something that does this. I can think of
a fairly easy and not-hugely-intensive implementation, too. I'd imagine
the canonical form for each variable would be an anagram
dictionary-style representation, with the letters arranged into
alphabetical order for storage/lookup.
Mead Raving
(er, I mean, Dave Ingram)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Case sensitivity
On Nov 7, 2008, at 12:59 AM, Ronald Chmara wrote: On Nov 6, 2008, at 6:27 PM, Nate Abele wrote: I was shocked and horrified that that ridiculous remove-the-$ post actually turned into a legitimate discussion. I mean, seriously? No, not seriously. [snip] The trick is knowing when a joke is intentional, or not. -Bop Hi Ronald, While it was obvious that some responses were farcical, if you review you'll clearly see that some responses were indeed explanatory discussion, describing why this approach would not work. This is completely unnecessary. This particular case non-withstanding, the instances where this occurs are numerous and regular. As another example, anyone with half a brain and more than 10 minutes experience with the internals of PHP knows that it'd be ridiculous to suggest that PHP's array type be re-written to act like Java or .NET. The fact that it is ridiculous is implicit, we all know it, it doesn't need to be said. Okay, now I'm done wasting everyone's time. I don't want to continue to exacerbate the very issue I'm speaking against, but please just consider it -- by responding to the noise, you're creating the very problem you want to solve through moderation. Show a little self- restraint (vis-a-vis http://xkcd.com/386/). (For the record, I am all for making the list read-only for anyone without karma. It'd make my morning routine much less aggravating.) Thanks, - Nate -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
On Fri, Nov 7, 2008 at 7:24 PM, Stan Vassilev | FM [EMAIL PROTECTED] wrote: What about adding a function that behaves like __autoload, but with respect to namespace wildcards? Something like: Hi, Ok so first: 1) We can't implement wildcards since a wildcard needs to be expanded to a set of concrete classes at runtime for it to make sense, and we don't know what those classes are (due to autoloads and conditional require/include constructs). 2) There can't be a method to resolve wildcards, since namespaces currently work 90% at the parse level, before any PHP code has executed. This is required for good performance and simplicity. 3) I have emailed Greg a simple idea for solving this with a INI-like meta namespace file, a simple file we can put in our include path, which describes the resources of a namespace and optionally their location. For example let's say you have namespace My\Name\Space, and inside you have classes Foo, Bar, functions baz and constants ONE, TWO. In one of your include paths, you'll create a file called My.Name.Space.nsmeta and put the following inside: class Foo = path\to\Foo.class.php class Bar = path\to\Bar.class.php function baz = path\to\baz.func.php const ONE = \path\to\constants.php const TWO = \path\to\constants.php This file you can generate from your framework, or even write by hand, as you see it's very simple to write/read, and tokenizes with the existing PHP tokenizer. Sounds like an idea for custom extension, but I doubt this would work as a general approach. It limits dynamic nature of php, so won't be suitable for all cases Did you see this extension? http://pecl.php.net/package/automap Since this file will be read at parse time, it has the ability to solve the following problems: 1) zero-performance-impact namespace wildcards (especially with an opcode cache like APC, XCache etc.) 2) faster resource loading (PHP can autoload resources from the location map above without you writing a slow __autoload runtime procedure) 3) you can load on demand now any namespace resources: class, functions, constant, not just classes. Naturally this is not for 5.3 as we all want 5.3 stable and out as soon as possible. But it has the potential to simplify drastically some workflows, especially in large complex frameworks, so if it picks up, maybe 5.4, or 6 or who knows. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Case sensitivity
As another example, anyone with half a brain and more than 10 minutes experience with the internals of PHP knows that it'd be ridiculous to suggest that PHP's array type be re-written to act like Java or .NET. The fact that it is ridiculous is implicit, we all know it, it doesn't need to be said. Hi, I don't know why case sensitivity as I layed it out, is put in the same group as ideas for removing $ from variables or redoing the PHP primitives, or what have you... Knowing the guts of PHP doesn't protect people from making really bad proposals, as anyone following this list for some time is well aware. Core devs know the PHP engine well, but sometimes have little idea of accepted standards, syntax and common workflows in and outside the PHP community. Also: those truly hilarious joke replies some people keep producing on this list, including to this thread: they're not funny. The idea of OSS forums like this list, isn't to generate easy entertainment for bored programmers. A valid point elsewhere is lost everytime a thread heads this way. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
Sounds like an idea for custom extension, but I doubt this would work as a general approach. It limits dynamic nature of php, so won't be suitable for all cases Did you see this extension? http://pecl.php.net/package/automap Just two points: 1) It doesn't need to be suitable for all cases, as you can still require/include or autoload your file exactly as today. It's an addition, not a replacement. 2) It doesn't limit the dynamic nature of PHP as those files can be generated from a script just as any text file, and will be used for large redistributable libraries, frameworks, which are more static in nature than the application code utilising them. As for the extension, I'll check it out, thanks. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] bracketed namespace declarations
Hi,
Stas and company decided that they wanted namespaces to have two legal
syntax choices:
1) single namespace per file:
?php
namespace foo;
...
?
2) multiple namespaces per file:
?php
namespace foo1 {
}
namespace foo2 {
}
?
I've implemented these two syntax options in a patch found at
http://pear.php.net/~greg/bracketed.patch.txt based on earlier work of
Dmitry Stogov.
It turns out there are some tricky details to work out, especially with
regard to importing via use statements. If we just allow global,
un-namespaced code, for instance, we could end up with this mess:
?php
use blah\blah;
$f = new blah;
namespace one {
use foo\bar as blah;
$a = new blah;
}
// what is this?
blah::hi();
?
Technically, you could argue that blah::hi() should resolve to
blah\blah::hi(), but it is very difficult to track and figure out what
blah means by eye. Thus, in the patch I implemented, if bracketed
namespace declarations exist, global use statements are not allowed, but
must exist within namespace ns {} brackets.
This creates a problem - how do you combine namespaced and unnamespaced
code? To solve this, I introduced the oft-suggested namespace {}
syntax for un-namespaced code. Thus, the above script would become:
?php
namespace {
use blah\blah;
$f = new blah;
}
namespace one {
use foo\bar as blah;
$a = new blah;
}
namespace {
use blah\blah;
blah::hi();
}
?
Another important point is that imports specified by the use statement
disappear when we exit a namespace block. This way, it is very easy to
combine un-namespaced code that uses namespaces, and namespaced code.
Also very important to note is that the namespace {} syntax is
optional for any code that does not import other things via the use
statement - its sole purpose is to provide a clear visual and logical
wrapper within which imports occur.
Thus, this is also legal:
?php
namespace newly\coded\stuff {
class mine { ... }
}
// old stuff here
class PEAR { ... }
?
Lastly, if global code does make use of namespaces, but does not import
anything, it can also happily co-exist with bracketed namespace code:
?php
namespace ns {
class mine { ... }
}
$a = new ns\mine;
// and so on
?
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] bracketed namespace declarations
?php
use blah\blah;
$f = new blah;
namespace one {
use foo\bar as blah;
$a = new blah;
}
// what is this?
blah::hi();
?
Technically, you could argue that blah::hi() should resolve to
blah\blah::hi(), but it is very difficult to track and figure out what
blah means by eye. Thus, in the patch I implemented, if bracketed
namespace declarations exist, global use statements are not allowed, but
must exist within namespace ns {} brackets.
This creates a problem - how do you combine namespaced and unnamespaced
code? To solve this, I introduced the oft-suggested namespace {}
...
Well, here's a cheesy mod of your example:
?php
$f = 10;
function one() {
$f = 20;
}
echo $f; // what is this? 10 ;)
?
I guess it's clear that code below or above a namespace is in the same
global namespace, so use blah\blah will apply ot blah::hi();.
However, we do also need your suggestion: namespace [nothing] { ... } since
one of the major design goals of the {} syntax variation was to allow people
to merge multiple files for deployment. Something which several frameworks
already do.
When we merge two files with use clauses, we need a way to provide blank
namespace scope so the use applies only to the relevant part of the code.
We can't avoid your code example above either, since by default we don't
require every piece of code to be in a namespace. If we allow {} scoping,
it'll be awkward to suddenly require the remaining global code to be put in
an explicit scope too, and people will be confused.
Hence a solution that seems most natural to me, and covers all use cases is
the following (where the scope # tells you where the use declarations
apply):
?php
// global, scope 1
namespace { // global, scope 2 }
// global, scope 1
namespace { // global, scope 3 }
// global, scope 1
namespace foo\bar { // foo\bar, scope 4 }
// global, scope 1
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] bracketed namespace declarations
Sorry for the second email, I just forgot to mention something regarding how
use statements apply from global scope to namespace x {}.
The best way regarding realworld usage and existing state of the art would
be to take into account the use statements in the scope above and apply the
use statements inside the scope after them.
So if I write this:
?php
use A;
use B;
namespace {
use C;
}
?
In the namespace, it's the same as if I wrote use A, B, C in that order
explicitly. Implemented this way, in a future version of PHP we could allow
this typical scenario (which I suspect won't work with this patch?):
?php
use A;
function foo() {
use B; // use A applies implicitly, use B applied only for the scope of
the function
...code...
}
?
Which code above is in fact a sugared version of what is actually happening:
?php
use A;
function foo() { namespace {
use B; // use A applies implicitly, use B applied only for the scope
of the namespace scope
...code...
} }
?
The above significantly helps with larger function/class libraries in a
single file, as you can make your use statements more local (typically you
will use certain classes globally, and most locally in a function/method),
and is supported by most modern languages that handle namespaces.
Regards, Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] bracketed namespace declarations
Stan Vassilev | FM wrote:
?php
// global, scope 1
namespace { // global, scope 2 }
// global, scope 1
namespace { // global, scope 3 }
// global, scope 1
namespace foo\bar { // foo\bar, scope 4 }
// global, scope 1
?
I am afraid I must shed my generally congenial public nature to express
a strong opinion:
This is a horribly complex idea Stan. PHP's implementation of
namespaces do not define scope. Once we open that Pandora's box, there
is no turning back.
Big time -1 from me.
Remember, the patch I'm proposing would only be necessary for people
using un-namespaced code combined with namespaced code (already a bad
idea) *and* scattering use statements throughout the global code.
Also, the *only* supported use case behind allowing multiple namespaces
per file is to allow people to mash pre-existing separate PHP files
together, and have them still compile. Requiring brackets is designed
to make it more readable, and the use restriction furthers that goal.
I would have implemented this requiring all code to be encased in
namespace {} or namespace nsname {}, but that turned out to be virtually
impossible in the parser because of the need to also allow declare
statements outside namespace declarations
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] bracketed namespace declarations
Hey there! Why don't you try an implementation as: namespace foo; (contents xyz) namespace foob; (contents xyz of as second called namespace) Wouldn't it be easier to make such an application tree instead of using the normal bracket-like opening? Your, -- (c) Kenan Sulayman Freelance Designer and Programmer Life's Live Poetry
Re: [PHP-DEV] [PATCH] bracketed namespace declarations
Hi, Ok so I had a quick chat with greg and reread his proposal and it's actually a sound proposal. My original concern was that if we don't implement proper subset of namespace scopes we'll have difficulty extending PHP in the future to support function-local use declarations etc. However Greg's proposal is in fact a strict subset of scopes, which could be extended in the future in a backcompat nature. It also covers all use cases by the community, so I'm +1, if anyone is counting that is. Sorry for the noise :) Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
