Re: [PHP-DEV] exception policy for core
On 19.10.2007, at 02:20, Larry Garfield wrote: On Thursday 18 October 2007, Lukas Kahwe Smith wrote: The possibility of changing the error mode at run-time makes it quite hard to read code. Since you always have to check the error mode of the object you're currently looking at. Therefore I think we should avoid adding more of these switches in future - especially on an per- object basis. Well I agree that this can be problematic. In the case of PDO one might be passing a PDO instance to various libraries, which may rely on exceptions being thrown or not. Personally I would not mind not throwing exceptions for anything but constructor errors (actually I think even those should be avoided), but that switch in PDO seemed like an acceptable balance. regards, Lukas I've actually had issues in the past with PDO and non-exception error-mode handling. I had queries that were running fine but when I checked the error value it gave a non-OK value. (I forget what off hand.) As soon as I switched to exceptions, it worked perfectly. I believe this was under 5.2.1. -- Well that sounds like a bug and not like a "feature" of exceptions. Or are you implying that the added complexity of this switch makes it harder to write bug free code. I do image that its a bit annoying to have to write tests to cover all the error modes. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exception policy for core
On Thursday 18 October 2007, Lukas Kahwe Smith wrote: > > The possibility of changing the error mode at run-time makes it quite > > hard to read code. Since you always have to check the error mode of > > the > > object you're currently looking at. Therefore I think we should avoid > > adding more of these switches in future - especially on an per-object > > basis. > > Well I agree that this can be problematic. In the case of PDO one > might be passing a PDO instance to various libraries, which may rely > on exceptions being thrown or not. Personally I would not mind not > throwing exceptions for anything but constructor errors (actually I > think even those should be avoided), but that switch in PDO seemed > like an acceptable balance. > > regards, > Lukas I've actually had issues in the past with PDO and non-exception error-mode handling. I had queries that were running fine but when I checked the error value it gave a non-OK value. (I forget what off hand.) As soon as I switched to exceptions, it worked perfectly. I believe this was under 5.2.1. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.2.5RC1 Released for Testing
The first release candidate of 5.2.5 was just released for testing and can be downloaded here: http://downloads.php.net/ilia/php-5.2.5RC1.tar.bz2 (md5sum: 2f0c9ecbd50213958e9b69ec69f715ec) The Windows binaries should become available shortly as well. Please test this release against your code and let us know if you come across any new problems or regressions. If all goes well, I anticipate RC2 within 2 weeks, followed by the final release a week later. I'd like to ask all developers to avoid making any changes in 5.2 branch that are not bug fixes and at the same time review the pending issues on bugs.php.net to see if any outstanding bugs can be fixed by RC2. Ilia Alshanetsky PHP 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exception policy for core
On 18.10.2007, at 12:29, Johannes Schlüter wrote: Hi, On Thu, 2007-10-18 at 11:45 +0400, Antony Dovgal wrote: On 17.10.2007 20:09, Lukas Kahwe Smith wrote: Hi, I remember that we discussed the question of exception throwing from core in the very early days of php 5, when the suggestion of turning all errors into exceptions first came up. I remember that we decided that exceptions should only be thrown from core on constructor errors by default. Along the lines of PDO, extensions could allow users to explicitly enable an exception mode. First of all, I have to say that I see nothing wrong in using exceptions. Second, I see nothing wrong in using exceptions _in OO extensions_. And finally, I don't like the idea of having a special function in each and every extension to control it's error level. PDO was built this way from the very beginning, but making this some kind of standard would be a mistake IMO. You may not like exceptions, but that doesn't make them less useful. The possibility of changing the error mode at run-time makes it quite hard to read code. Since you always have to check the error mode of the object you're currently looking at. Therefore I think we should avoid adding more of these switches in future - especially on an per-object basis. Well I agree that this can be problematic. In the case of PDO one might be passing a PDO instance to various libraries, which may rely on exceptions being thrown or not. Personally I would not mind not throwing exceptions for anything but constructor errors (actually I think even those should be avoided), but that switch in PDO seemed like an acceptable balance. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
Am 18.10.2007 um 18:06 schrieb Stanislav Malyshev: I would prefer Stan's patch to allow keyword to be used as class/method/function name. At the very least (the patch has A note here: the solution we have doesn't allow _any_ keyword to be used as name. Only import keyword, for supporting old code. That certainly sounds nasty. Why not just use "use" then, it's reserved already anyway. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 5.2.4 test results reference
I know, I know.. It is on my TODO list for a loong time. I have the program on my head, I just need to get some time to sit and code it.. BTW: Jean, would Sun be interested in setting up a build machine to run the PHP test suite and post the results to a central build DB? Nuno - Original Message - Hello Nuno, we should work on that database thing that collects information from trusted gcov machines. marcus Wednesday, October 17, 2007, 11:03:47 PM, you wrote: we would like to know whether at php org level there are any test results available / published / shared per OS (like Solaris, RH in particular) Not grouped, but we do have all the test results here: http://news.php.net/php.qa In addition to what Derick said, there is a "reference" build and test failure at http://gcov.php.net Nuno Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP DOM] Proposal of boolean property DOMDocument::keepCharacterEntities
Not the place for a feature request and not going to happen. It is not supported in libxml2 because it is against the XML specs. Rob Freyjkell wrote: (bool) DOMDocument::keepUnknownCharacterEntities = false; If set to true (before calling DOMDocument::load() or DOMDocument::loadXML()), when parser will occur an unknown entity, it won't crash, but let it alone. In DOMNode::textContent, DOMNode::getAttribute() and similar, they will be omitted. During importing it to another document, they will be moved without any changes. It could be useful for editing XHTML documents. DOMDocument::resolveExternals is very slow. Even if DTD is on disk, it includes many crappy code (i.e. references to XML Schema). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object arithmetic
Stanislav Malyshev wrote: While looking at bug 42780: http://bugs.php.net/bug.php?id=42780 The only way not to lose precision is to explicitly cast the object to float or string, which just doesn't seem right to me. I'm not sure how this can be fixed - there should be some type used and many objects won't provide convertor to float... Anyway, it's probably not the best idea to rely on default conversion in this context - better to specify it. I would have agreed 100% that explicit casting should be used, but with to_string around, it just doesn't seem right now.Take the following: $xml = '1.12.2'; $sxe = simplexml_load_string($xml); print $sxe->a ." + ".$sxe->b." = ".($sxe->a +$sxe->b); 1.1 + 2.2 = 3 And why wouldn't objects provide a float converter? If they provided a converter to long why wouldn't they also provide means to convert to float. Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
why even discuss import? We already decided for use and reserved is as a "We" being? keyword long ago. And for the other one, well package is anyway much better. I vaguely remember having discussion on this already... Anyway, package won't solve any of the problems we are currently discussing - there's a bunch of apps using package as identifier, starting with PEAR. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
Hello Stanislav, why even discuss import? We already decided for use and reserved is as a keyword long ago. And for the other one, well package is anyway much better. marcus Thursday, October 18, 2007, 7:04:28 PM, you wrote: >> Others: concern about T_IMPORT breaking BC is also moot. There is an >> instant parse error on this declaration: >> >> > namespace whatever; >> ?> > This is not related to BC. What is related to BC is that applications > like Propel or Wordpress stopping working with 5.3 since they use import > as identifier. Unfortunately we also have some package using "namespace" > as identifier (e.g. ezPublish for methods, mediawiki for class) but not > too many. > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
Stanislav Malyshev wrote:
>> Are there already any results on these checks?
>
> Looks like we have the simple patch that allows to use "import" as
> method name, function name and class name. If we didn't discover any
> problems with it then import stays.
Hi,
If you're talking about my patch [1], the restriction is only lifted for
method names. I don't think it is even possible for functions:
function foreach() {return array(1);}
foreach(foreach() as $oops);
The above code requires PHP to parse all the way to the T_AS prior to
determining whether the first foreach statement is a T_STRING or a
T_FOREACH.
It may be possible for classes, but is much more complex, so I did not
go that route. For instance:
class class {
static function class(){}
}
$a = class::class();
$a = new class;
We can safely expect a T_STRING after T_NEW, but in open global scope,
we would need to match an identifier plus :: before matching any
keyword. It is possible, but somewhat messier.
Methods, on the other hand, are simple, as the 11-line patch
demonstrates. We always know that stuff after T_OBJECT_OPERATOR and
T_PAMMAYAMMAETC should be a T_STRING. In fact, this is already possible
for variables as in this example (T_STRING returned for "class"):
class blah {
var $class;
}
$a = new blah;
$a->class = 1;
but as I said in the bug report, this example breaks (T_CLASS returned
for "class"):
class blah {
var $class;
}
$a = new blah;
$a-> class = 1;
because the lexer fails to take into account whitespace properly when
looking for a property (also fixed in my patch).
Andi: your concern about highlighters is moot - implementing the changes
to always detect T_STRING after :: or -> is trivial no matter how dumb
the highlighter is :).
Others: concern about T_IMPORT breaking BC is also moot. There is an
instant parse error on this declaration:
The only way to "preserve" BC (no parse error) would be to use some
weirdo syntax like
This might be an option, but I don't see much point - the code still
will fail to work because it uses namespaces. Namespaces are new, the
syntax *should* break BC, otherwise we'll get all kinds of weird bug
reports from users using PHP versions that are too old.
My patch prevents breakage of Zend Framework and Symfony because nobody
who has followed the CS rule of "use underscores to avoid conflicting
with internal classes" is using "class import" "class namespace" or
interface equivalents.
Greg
[1] http://bugs.php.net/bug.php?id=28261
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PHP DOM] Proposal of boolean property DOMDocument::keepCharacterEntities
(bool) DOMDocument::keepUnknownCharacterEntities = false; If set to true (before calling DOMDocument::load() or DOMDocument::loadXML()), when parser will occur an unknown entity, it won't crash, but let it alone. In DOMNode::textContent, DOMNode::getAttribute() and similar, they will be omitted. During importing it to another document, they will be moved without any changes. It could be useful for editing XHTML documents. DOMDocument::resolveExternals is very slow. Even if DTD is on disk, it includes many crappy code (i.e. references to XML Schema). -- Freyjkell JID: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
Others: concern about T_IMPORT breaking BC is also moot. There is an instant parse error on this declaration: This is not related to BC. What is related to BC is that applications like Propel or Wordpress stopping working with 5.3 since they use import as identifier. Unfortunately we also have some package using "namespace" as identifier (e.g. ezPublish for methods, mediawiki for class) but not too many. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 5.2.4 test results reference
Hello Nuno, we should work on that database thing that collects information from trusted gcov machines. marcus Wednesday, October 17, 2007, 11:03:47 PM, you wrote: >>> we would like to know whether at php org level there are any test >>> results available / published / shared per OS (like Solaris, RH in >>> particular) >> >> Not grouped, but we do have all the test results here: >> http://news.php.net/php.qa > In addition to what Derick said, there is a "reference" build and test > failure at http://gcov.php.net > Nuno Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exception policy for core
Hello Derick, right, maybe we need writen down rules easy to read for pecl and core other then the CODING_STYLES bile. marcus Wednesday, October 17, 2007, 7:38:56 PM, you wrote: > On Wed, 17 Oct 2007, Lukas Kahwe Smith wrote: >> Hi, >> >> I remember that we discussed the question of exception throwing from core in >> the very early days of php 5, when the suggestion of turning all errors into >> exceptions first came up. I remember that we decided that exceptions should >> only be thrown from core on constructor errors by default. Along the lines of >> PDO, extensions could allow users to explicitly enable an exception mode. >> >> This popped up again as I picked up on IRC that the imagick extension is >> quite >> exception throwing happy. I do realize that this is a pecl extension, so >> maybe >> core rules do not apply (core<->pecl relations should also be addressed ASAP >> if you ask me). >> >> Anywas, am I remembering things correctly? Is this still our policy? If not >> do >> we have (want?) a policy? > In my opinion, this is still the policy that should be added to the CS. > regards, > Derick > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] Method overloading by method signature
Hello Umberto,
Monday, October 15, 2007, 3:36:22 PM, you wrote:
> Posting to newsgroup php.internals, Stanislav Malyshev wrote:
>> > only reason to use type hints - to ensure the method is used
>> > correctly and build more robust applications), it is better to tell
>>
>> BTW, I'm not sure how exactly it makes the code more robust - if you
>> call it with wrong type and it's not checked, the app would probably die
>> on fatal error. If you call it with wrong type and it is checked, the
>> app would die on fatal error couple of lines above. Unless you use some
>> kind of static analysis tool to verify your app prior to deployment (if
>> you know such tools please tell me!) I don't see much difference here,
>> mostly syntax sugar and enforcing right style (which is not bad - just
>> it's not that big a deal).
> Most of the current applications of PHP do not need strict type checking, and
> PHP as we know today perfectly fits these needs. But debugging and "cleaning"
> large applications may become a nightmare.
> That's why I developed PHPLint,
I think this is a very nice tool and the way to go in PHP. You should
showcase demo it on one of the conferences! And provide links here of
course :-)
marcus
> a PHP parser and validator that performs
> a static analysis of the source, ensuring the safe handling of types. In
> a word, this tool makes PHP very close to a strong-typed language without
> the need to further complicate the interpreter with new features that would
> pervert the nature of the language.
> Every constant, variable, property has a well defined type, and every
> function and method has a well defined signature that can be guessed by
> PHPLint or provided through specific meta-code as in this example:
> $i = 123;
> # type of the variable guessed as int
> define("RND_K", 1.0 / (1.0 + getrandmax()));
> # type of the constant guessed as double
> function rnd()
> {
> return RND_K * rand();
> }
> # signature guessed as float()
> $i = rnd();
> # ERROR: assigning double to int
> function textToattribute(/*.string.*/ $a)
> {
> return "\"" . htmlspecialchars($a) . "\"";
> }
> # signature string(string)
> Best regards,
> ___
> /_|_\ Umberto Salsi
> \/_\/ www.icosaedro.it
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object arithmetic
In this case, the proper solution is to force SimpleXML to cast values to strings, because, after all, XML has nothing but strings. Then + operator requires numeric values. SimpleXML can't return string when asked for numeric value. The problem is while + can accept both int and float, it can't ask for both. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
I would prefer Stan's patch to allow keyword to be used as class/method/function name. At the very least (the patch has A note here: the solution we have doesn't allow _any_ keyword to be used as name. Only import keyword, for supporting old code. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
Hi, On 10/18/07, Johannes Schlüter <[EMAIL PROTECTED]> wrote: > On Thu, 2007-10-18 at 12:08 +0200, Pierre wrote: > > I would prefer Stan's patch to allow keyword to be used as > > class/method/function name. At the very least (the patch has > > unsolvable issues), I have to agree with Andi, we should just go with > > "use" (codesearch returns less than 10 results :). > > The point about using "use" is that "use" is already a reserved keyword > in PHP - therefore we can't break anything by using "use" for > namespaces. Oh, I missed this point. So what are we waiting for to switch? It will ease our life to test our existing code under 5.3 without having to create specific branches (or breaking bc). >So in this single case we have a chance of using a keyword > withou breaking anything (while we still might break stuff due to the > "namespace" keyword) :-) The namespace keyword is less a problem than import. It is mostly used in areas where php5+ provides native solution (for example xml or soap like in ezpublish, mostly php4 code). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exception policy for core
Hi, On Thu, 2007-10-18 at 11:45 +0400, Antony Dovgal wrote: > On 17.10.2007 20:09, Lukas Kahwe Smith wrote: > > Hi, > > > > I remember that we discussed the question of exception throwing from > > core in the very early days of php 5, when the suggestion of turning > > all errors into exceptions first came up. I remember that we decided > > that exceptions should only be thrown from core on constructor errors > > by default. Along the lines of PDO, extensions could allow users to > > explicitly enable an exception mode. > > First of all, I have to say that I see nothing wrong in using exceptions. > Second, I see nothing wrong in using exceptions _in OO extensions_. > And finally, I don't like the idea of having a special function in each and > every extension to control it's error level. > PDO was built this way from the very beginning, but making this some kind of > standard would be a mistake IMO. > > You may not like exceptions, but that doesn't make them less useful. The possibility of changing the error mode at run-time makes it quite hard to read code. Since you always have to check the error mode of the object you're currently looking at. Therefore I think we should avoid adding more of these switches in future - especially on an per-object basis. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
Hi, On Thu, 2007-10-18 at 12:08 +0200, Pierre wrote: > I would prefer Stan's patch to allow keyword to be used as > class/method/function name. At the very least (the patch has > unsolvable issues), I have to agree with Andi, we should just go with > "use" (codesearch returns less than 10 results :). The point about using "use" is that "use" is already a reserved keyword in PHP - therefore we can't break anything by using "use" for namespaces. So in this single case we have a chance of using a keyword withou breaking anything (while we still might break stuff due to the "namespace" keyword) :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT vs. T_USE
On 10/18/07, Andi Gutmans <[EMAIL PROTECTED]> wrote: > Main problem I have right now after digging deeper is that any such "fix" in > the parser will mean that tokenizers and syntax highlighters will not treat > keywords like "import" correctly. Fixing this would require them to do > parsing which in many cases you don't want to do. There are a lot of > utilities and tools which depend on such behavior. > Even if it's just for this reason it may be better if we stick to the "a > keyword is a keyword" rule and don't try and outsmart ourselves (other > languages like C have discovered the same issues and stuck to the keyword > only rule too). So it may make most sense to go ahead and use "use". If we stick to this rule, we can't add new keywords in minor/patch versions. (x.y+1 or x.y.z+1) as it break BC. With import, a lot of codes is affected even if they use "import" as method name (said already, add symfony to the list). I really don't care about use or import but for what I see, import is going to break (as said already) a lot of apps/codes out ther (add symfony to the list). I would prefer Stan's patch to allow keyword to be used as class/method/function name. At the very least (the patch has unsolvable issues), I have to agree with Andi, we should just go with "use" (codesearch returns less than 10 results :). Cheers, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new feature -> with()
Sebastian wrote:
[...] what i'm suggesting is,
that in with(){} you are only allowed to use the methods and variables
defined in the object you are using with(). as in the sample, you are not
using any global functions or else.
this would render 'with' mostly useless as in most
real world situations where a 'with' block might
make sense it wouldn't be standalone but would
at least require some basic function calls to
be of use ...
so with this limitation in place i'd like to revert
my previous -0.9 to a strong -1
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exception policy for core
On 17.10.2007 20:09, Lukas Kahwe Smith wrote: > Hi, > > I remember that we discussed the question of exception throwing from > core in the very early days of php 5, when the suggestion of turning > all errors into exceptions first came up. I remember that we decided > that exceptions should only be thrown from core on constructor errors > by default. Along the lines of PDO, extensions could allow users to > explicitly enable an exception mode. First of all, I have to say that I see nothing wrong in using exceptions. Second, I see nothing wrong in using exceptions _in OO extensions_. And finally, I don't like the idea of having a special function in each and every extension to control it's error level. PDO was built this way from the very beginning, but making this some kind of standard would be a mistake IMO. You may not like exceptions, but that doesn't make them less useful. > This popped up again as I picked up on IRC that the imagick extension > is quite exception throwing happy. I do realize that this is a pecl > extension, so maybe core rules do not apply (core<->pecl relations > should also be addressed ASAP if you ask me). > > Anywas, am I remembering things correctly? Is this still our policy? > If not do we have (want?) a policy? While I agree that there should be some kind of recommendations/standards, IMO they should not include such a clause. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
