[PHP-DEV] [PATCH] sapi/apache2*: Use ap_state_query where possible instead of old method of creating a pool userdata entry.
---
sapi/apache2filter/sapi_apache2.c | 11 +--
sapi/apache2handler/sapi_apache2.c | 12 ++--
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/sapi/apache2filter/sapi_apache2.c
b/sapi/apache2filter/sapi_apache2.c
index a8fec5c..21f2fa3 100644
--- a/sapi/apache2filter/sapi_apache2.c
+++ b/sapi/apache2filter/sapi_apache2.c
@@ -606,11 +606,17 @@ static int
php_apache_server_startup(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp, server_rec *s)
{
+
+#if AP_MODULE_MAGIC_AT_LEAST(20110203,1)
+/* Apache will load, unload and then reload a DSO module. This
+ * prevents us from starting PHP until the second load. */
+ if (ap_state_query(AP_SQ_MAIN_STATE) == AP_SQ_MS_CREATE_PRE_CONFIG) {
+return OK;
+ }
+#else
void *data = NULL;
const char *userdata_key = apache2filter_post_config;
- /* Apache will load, unload and then reload a DSO module. This
-* prevents us from starting PHP until the second load. */
apr_pool_userdata_get(data, userdata_key, s-process-pool);
if (data == NULL) {
/* We must use set() here and *not* setn(), otherwise the
@@ -622,6 +628,7 @@ php_apache_server_startup(apr_pool_t *pconf, apr_pool_t
*plog,
apr_pool_cleanup_null, s-process-pool);
return OK;
}
+#endif
/* Set up our overridden path. */
if (apache2_php_ini_path_override) {
diff --git a/sapi/apache2handler/sapi_apache2.c
b/sapi/apache2handler/sapi_apache2.c
index 900a3a4..a578740 100644
--- a/sapi/apache2handler/sapi_apache2.c
+++ b/sapi/apache2handler/sapi_apache2.c
@@ -430,12 +430,19 @@ static int php_pre_config(apr_pool_t *pconf, apr_pool_t
*plog, apr_pool_t *ptemp
static int
php_apache_server_startup(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t
*ptemp, server_rec *s)
{
- void *data = NULL;
- const char *userdata_key = apache2hook_post_config;
+#if AP_MODULE_MAGIC_AT_LEAST(20110203,1)
/* Apache will load, unload and then reload a DSO module. This
* prevents us from starting PHP until the second load. */
+if (ap_state_query(AP_SQ_MAIN_STATE) == AP_SQ_MS_CREATE_PRE_CONFIG) {
+ return OK;
+}
+#else
+ void *data = NULL;
+ const char *userdata_key = apache2hook_post_config;
+
apr_pool_userdata_get(data, userdata_key, s-process-pool);
+
if (data == NULL) {
/* We must use set() here and *not* setn(), otherwise the
* static string pointed to by userdata_key will be mapped
@@ -445,6 +452,7 @@ php_apache_server_startup(apr_pool_t *pconf, apr_pool_t
*plog, apr_pool_t *ptemp
apr_pool_userdata_set((const void *)1, userdata_key,
apr_pool_cleanup_null, s-process-pool);
return OK;
}
+#endif
/* Set up our overridden path. */
if (apache2_php_ini_path_override) {
--
1.7.10.4
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] sapi/apache2*: Use ap_state_query where possible instead of old method of creating a pool userdata entry.
On 08/08/2012 10:33 AM, Cristian Rodríguez wrote: sapi/apache2filter/sapi_apache2.c | 11 +-- sapi/apache2handler/sapi_apache2.c | 12 ++-- 2 files changed, 19 insertions(+), 4 deletions(-) Patches to the mail list are very likely to get lost. It's probably better to attach them to a bug at https://bugs.php.net and/or do a pull request at https://github.com/php/php-src Since there wasn't any response to your previous patch, you will likely also need to follow up to ensure the code gets merged or rejected. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix per-module logging in apache 2.4
hi Chirstian!
Could you please either (or both :) open a bug and attach the patch to
it or create a pull request please?
Thanks for your work!
Cheers,
On Mon, Aug 6, 2012 at 11:59 PM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:
---
sapi/apache2filter/sapi_apache2.c |3 +++
sapi/apache2handler/mod_php5.c|4
2 files changed, 7 insertions(+)
diff --git a/sapi/apache2filter/sapi_apache2.c
b/sapi/apache2filter/sapi_apache2.c
index 0b51cfb..a8fec5c 100644
--- a/sapi/apache2filter/sapi_apache2.c
+++ b/sapi/apache2filter/sapi_apache2.c
@@ -744,6 +744,9 @@ static size_t php_apache_fsizer_stream(void *handle
TSRMLS_DC)
return 0;
}
+#ifdef APLOG_USE_MODULE
+APLOG_USE_MODULE(php5);
+#endif
AP_MODULE_DECLARE_DATA module php5_module = {
STANDARD20_MODULE_STUFF,
create_php_config, /* create per-directory config
structure */
diff --git a/sapi/apache2handler/mod_php5.c b/sapi/apache2handler/mod_php5.c
index 9df4f25..35d5548 100644
--- a/sapi/apache2handler/mod_php5.c
+++ b/sapi/apache2handler/mod_php5.c
@@ -25,6 +25,10 @@
#include php.h
#include php_apache.h
+#ifdef APLOG_USE_MODULE
+APLOG_USE_MODULE(php5);
+#endif
+
AP_MODULE_DECLARE_DATA module php5_module = {
STANDARD20_MODULE_STUFF,
create_php_config, /* create per-directory config
structure */
--
1.7.10.4
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Pierre
@pierrejoye | 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] [PATCH] Fix per-module logging in apache 2.4
El 08/08/12 15:38, Pierre Joye escribió: hi Chirstian! Could you please either (or both :) open a bug and attach the patch to it or create a pull request please? I opened a pull request a few minutes ago., https://github.com/php/php-src/pull/154 Cheers ! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Fri, Jul 27, 2012 at 8:09 PM, Nikita Popov nikita@gmail.com wrote: 5. Are multiple yields allowed? I.e. the rfc mentions something like yield yield $a - what that would mean? I'd allow yield only be applied to variable expression (lval) because double yield doesn't make sense to me, but maybe I miss something. yield yield $a would basically first yield $a and then receive some value (via send) and yield that value again. Nothing you'd normally do ;) It was mentioned only as a syntax ambiguity consideration. Actually I added some additional parenthesis requirements for yield. For example you'd have to write the above as `yield (yield $a)` now (which should be slightly more clear). I haven't yet reflected this change in the RFC, but I'll add a section on it later. 6. “Sending values” section seems to be missing. Especially useful would be to cover what happens with keys there and what is the syntax there - is it just $a = yield;? Or does it mean when yield is used in expression it becomes incoming yield? And, last but not least - do we need sending into generators at all? Yeah, I haven't written that section yet. But it is fairly simple: If you go $generator-send($foo) then $foo will be the result of the current `yield` expression. And yes, this also works with keys and values. All of the following are valid: $data = yield; $data = (yield $value); $data = (yield $key = $value); The first case is the most common though. I.e. you usually use it either as a generator or a reverse generator, not both. But doing both is also common for cooperative multitasking etc. Regarding the last question: I think the feature is worth adding. It is a very powerful concept that is hard to implement otherwise. Useful in particular for things like parsing and multitasking. 6. What happens if you send into a by-ref generator? Is the data sent by-ref then? What if it's an expression that can't be send by-ref? No, sending is always by-value. By-ref only affects the yielding part. I now added the mentioned sections: https://wiki.php.net/rfc/generators#yield_keyword https://wiki.php.net/rfc/generators#sending_values I also added a list of error conditions: https://wiki.php.net/rfc/generators#error_conditions Sorry for the delay, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On 08/08/12 21:14, Nikita Popov wrote:
On Fri, Jul 27, 2012 at 8:09 PM, Nikita Popov nikita@gmail.com wrote:
5. Are multiple yields allowed? I.e. the rfc mentions something like
yield yield $a - what that would mean? I'd allow yield only be applied
to variable expression (lval) because double yield doesn't make sense to
me, but maybe I miss something.
yield yield $a would basically first yield $a and then receive some
value (via send) and yield that value again. Nothing you'd normally do
;) It was mentioned only as a syntax ambiguity consideration.
Actually I added some additional parenthesis requirements for yield.
For example you'd have to write the above as `yield (yield $a)` now
(which should be slightly more clear). I haven't yet reflected this
change in the RFC, but I'll add a section on it later.
6. “Sending values” section seems to be missing. Especially useful would
be to cover what happens with keys there and what is the syntax there -
is it just $a = yield;? Or does it mean when yield is used in
expression it becomes incoming yield? And, last but not least - do we
need sending into generators at all?
Yeah, I haven't written that section yet. But it is fairly simple: If
you go $generator-send($foo) then $foo will be the result of the
current `yield` expression. And yes, this also works with keys and
values. All of the following are valid:
$data = yield;
$data = (yield $value);
$data = (yield $key = $value);
The first case is the most common though. I.e. you usually use it
either as a generator or a reverse generator, not both. But doing both
is also common for cooperative multitasking etc.
Regarding the last question: I think the feature is worth adding. It
is a very powerful concept that is hard to implement otherwise. Useful
in particular for things like parsing and multitasking.
6. What happens if you send into a by-ref generator? Is the data sent
by-ref then? What if it's an expression that can't be send by-ref?
No, sending is always by-value. By-ref only affects the yielding part.
I now added the mentioned sections:
https://wiki.php.net/rfc/generators#yield_keyword
https://wiki.php.net/rfc/generators#sending_values
I also added a list of error conditions:
https://wiki.php.net/rfc/generators#error_conditions
Sorry for the delay,
Nikita
Hi Nikita,
I notice you require brackets round yield $k = $v and yield $v. Is this
the formal syntax, i.e. '(' T_YIELD var = var ')'? If so it makes sense
in a way, but it feels a little hackish. Does yield $v cause some sort
of parsing issue that putting it in brackets solves? I realise that it's
less ambiguous, but I don't like the idea of it. PHP's syntax has enough
special cases already IMO.
Regards,
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Wed, Aug 8, 2012 at 10:27 PM, Andrew Faulds a...@ajf.me wrote:
Hi Nikita,
I notice you require brackets round yield $k = $v and yield $v. Is this the
formal syntax, i.e. '(' T_YIELD var = var ')'? If so it makes sense in a
way, but it feels a little hackish. Does yield $v cause some sort of parsing
issue that putting it in brackets solves? I realise that it's less
ambiguous, but I don't like the idea of it. PHP's syntax has enough special
cases already IMO.
Without parenthesis their behavior in array definitions and nested
yields is ambigous:
array(yield $key = $value)
// can be either
array((yield $key) = $value)
// or
array((yield $key = $value))
yield yield $key = $value;
// can be either
yield (yield $key) = $value;
// or
yield (yield $key = $value);
Apart from that particular case there is the general operator
precedence inclarity, e.g.
yield $foo . $bar;
// could be
(yield $foo) . $bar;
// or
yield ($foo . $bar);
This obviously is not a problem per-se, but with yield-style unary
operators the precedence rules are often hard to figure out. E.g. most
people would probably think that
if (include('foo.php') == true) { ... }
would be check the return value of include, but it's actually not.
Rather it includes the file ('foo.php') == true, which is ''.
Another issue was a purely implementational: In order to support
by-ref yielding I have to distinguish between variable and
non-variable expressions, which breaks the usual precedence rules. I
was not able to fix the shift/reduce conflicts that are created by
this without requiring the parenthesis.
Also I'd like to mention that Python also has the paren-requirement
for yield-expressions. It even requires parens for a simple yield,
i.e. you'd have to write data = (yield). This is not necessary in
PHP, because PHP has semicolons.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
Hi!
https://wiki.php.net/rfc/generators#yield_keyword
https://wiki.php.net/rfc/generators#sending_values
I'm not sure $data = (yield $value) makes a lot of sense. Why we have
two variables here? Why it is only operator in the language that
requires parentheses around? All these complex parentheses rules seem
unnecessarily complicated. I'd rather do it in a more simple way: yield
in an expression means incoming yield. I.e.:
$data = yield;
foo(yield, 1, 2);
list($a, $b) = yield;
Same with:
call(yield $value) - what is the meaning of $value here? Why not just
call(yield)?
I would also not support array((yield $key = $value)) - it seems to be
really unclear how it works. I'd just have yield produce a value which
was sent, and that's it, and you could use this value in the same way
you'd use any other expression.
Only question I have here is what happens if you use yield in the middle
of function call expression, for example:
call(foo(bar(), $foo, yield, 3), baz());
We are kind of stopping the function in the middle of the function call
and going to unrelated code here, and may never return back. Where the
required cleanups, etc. should happen?
Another question is, if my function is like this:
function foo()
{
var_dump(yield);
}
And I do: foo()-current() - what happens? Do I get null there? What
happens if after that I do send() on the same generator? In general,
interaction between incoming and outgoing yields is not very clear,
especially what happens when you combine them.
Also, small point: yield is repeatably called statement in the doc,
but in fact it can be both statement and expression with returning yield.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On 08/08/12 21:43, Stas Malyshev wrote:
Hi!
https://wiki.php.net/rfc/generators#yield_keyword
https://wiki.php.net/rfc/generators#sending_values
I'm not sure $data = (yield $value) makes a lot of sense. Why we have
two variables here? Why it is only operator in the language that
requires parentheses around? All these complex parentheses rules seem
unnecessarily complicated. I'd rather do it in a more simple way: yield
in an expression means incoming yield. I.e.:
$data = yield;
foo(yield, 1, 2);
list($a, $b) = yield;
Same with:
call(yield $value) - what is the meaning of $value here? Why not just
call(yield)?
I would also not support array((yield $key = $value)) - it seems to be
really unclear how it works. I'd just have yield produce a value which
was sent, and that's it, and you could use this value in the same way
you'd use any other expression.
Only question I have here is what happens if you use yield in the middle
of function call expression, for example:
call(foo(bar(), $foo, yield, 3), baz());
We are kind of stopping the function in the middle of the function call
and going to unrelated code here, and may never return back. Where the
required cleanups, etc. should happen?
Another question is, if my function is like this:
function foo()
{
var_dump(yield);
}
And I do: foo()-current() - what happens? Do I get null there? What
happens if after that I do send() on the same generator? In general,
interaction between incoming and outgoing yields is not very clear,
especially what happens when you combine them.
Also, small point: yield is repeatably called statement in the doc,
but in fact it can be both statement and expression with returning yield.
Hmm. This is just a quick thought:
Considering the yield syntax will vary about needing () round it, why
not make it a fake function (language construct).
This way it's consistent: yield(), yield($v), yield($k = $v), $a =
yield(), etc.
(yield $x) is just messy as an expression. We don't have (isset $x), we
have isset($x).
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
On 07/27/2012 07:23 AM, Lester Caine wrote:
Nikita Popov wrote:
I'll ask again since no one has answered ...
In a different way ...
Is the only thing that changes the 'function' into a 'generator'
replacing
the call to process the data with 'yield'? ( That would be
'SUSPEND' in an
SQL procedure ) ...
So how DOES an IDE work out the flow in order to correctly check that
variables are defined?
As always, my IDE provides a lot of 'sexy' stuff so that I don't
need to
have it built in to the language, and I still can't see how a lot
of what is
being loaded in helps with performance which is the only thing that
I am
interested in. Performance wise why is yield better than just directly
calling a function to handle the data?
Lester Caine and Alex Aulbach,
may I ask you to continue this discussion in a separate thread? I am
really interested in constructive responses about the generator RFC,
but your discussion is generating a lot of noise, which makes it very
hard for me to pick out the few mails that are of interest to me.
If you could open a new thread (like Generator keyword) it would
help a lot.
Nikita - I am looking for a well reasoned argument as to why generator
has to be added at all! 'Just because it can be' is not a valid
argument, but perhaps you could add to the RFC the performance
implication or advantage of what is being proposed. That would at
least be some comparison with the current methods of doing the same
thing?
Anthony had a very good writeup on generators and how they compare to
iterators last week:
http://blog.ircmaxell.com/2012/07/what-generators-can-do-for-you.html
I think that does a good job of laying out the case for generators as
low-effort iterators.
I still think the syntax feels clunky to me, but that's probably because
I'm not used to it from other languages.
One question, though: It looks based on the voting like finally {}
blocks are going in. So... what should happen in the following situation:
function stuff() {
try {
foreach (range(1, 100) as $i) {
yield $i;
}
}
finally {
print All done;
}
}
Does All done get printed once, or 101 times? Similarly:
function things() {
$i = 1;
try {
while (true) {
yield $i++;
}
}
finally {
print All done;
}
}
That will run indefinitely. So will All done ever print, or does that
finally become unreachable?
(I have no clue what the behavior should be in these cases, just that
it should be sorted out sooner rather than later.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
One question, though: It looks based on the voting like finally {} blocks
are going in. So... what should happen in the following situation:
function stuff() {
try {
foreach (range(1, 100) as $i) {
yield $i;
}
}
finally {
print All done;
}
}
Does All done get printed once, or 101 times? Similarly:
function things() {
$i = 1;
try {
while (true) {
yield $i++;
}
}
finally {
print All done;
}
}
That will run indefinitely. So will All done ever print, or does that
finally become unreachable?
(I have no clue what the behavior should be in these cases, just that it
should be sorted out sooner rather than later.)
Based on my understanding of both RFCs, I don't see that this would be
a conflict or lead to unexpected behavior. As stated by the generators
RFC: When you first call the generator function ($lines =
getLinesFromFile($fileName)) the passed argument is bound, but nothing
of the code is actually executed. Instead the function directly
returns a Generator object..
So in the event we are calling the function stuff(), nothing should
actually be executed, and as we iterate over the traversable object
the generator should be passing control back and forth between the
generator and the calling code. This would be indicated by the
yield keyword present in the function. Meaning you should see the
expected result and finally should only ever be called once in your
first example.
As for you second example... Obviously if you've created an infinite
loop you've made everything outside of the loop unreachable, whether
you're using generators or not.
However, I'll let the author of the RFC provide any clarification or
corrections where I might be wrong.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] Re: Generators in PHP
On 2012-08-09 14:25, Larry Garfield wrote:
On 07/27/2012 07:23 AM, Lester Caine wrote:
Nikita - I am looking for a well reasoned argument as to why generator
has to be added at all! 'Just because it can be' is not a valid
argument, but perhaps you could add to the RFC the performance
implication or advantage of what is being proposed. That would at
least be some comparison with the current methods of doing the same
thing?
Anthony had a very good writeup on generators and how they compare to
iterators last week:
http://blog.ircmaxell.com/2012/07/what-generators-can-do-for-you.html
I think that does a good job of laying out the case for generators as
low-effort iterators.
I for one am lazy, and would much prefer writing:
?php
function append_iterator($first, $second)
{
foreach($first as $i)
{
yield $i;
}
foreach($second as $i)
{
yield $i;
}
}
?
to
?php
function append_iterator($first, $second)
{
if(is_object($first) !($first instanceof Iterator))
{
$first = (array)$first;
}
if(is_array($first))
{
$first = new ArrayIterator($first);
}
if(is_object($second) !($second instanceof Iterator))
{
$second = (array)$second;
}
if(is_array($second))
{
$second = new ArrayIterator($second);
}
return new myAppendIterator($first, $second);
}
class myAppendIterator implements Iterator
{
private $_state = 0;
private $_key;
private $_current;
private $first, $second;
public function __construct($first, $second)
{
$this-first = $first;
$this-second = $second;
}
public function rewind()
{
$this-first-rewind();
$this-second-rewind();
$this-state = 0;
}
public function current()
{
return $this-_current;
}
public function key()
{
return $this-_key;
}
public function next()
{
switch($this-_state)
{
case -1:
return;
case 0:
$this-first-rewind();
$this-_state = 1;
case 1:
if($this-first-valid())
{
$this-_current = $this-first-current();
$this-_key = $this-first-key();
$this-first-next();
return;
}
else
{
$this-second-rewind();
$this-_state = 2;
}
case 2:
if($this-second-valid())
{
$this-_current = $this-second-current();
$this-_key = $this-second-key();
$this-second-next();
return;
}
else
{
$this-_state = -1;
return;
}
}
}
public function valid()
{
return $this-_state != -1;
}
}
?
One question, though: It looks based on the voting like finally {}
blocks are going in. So... what should happen in the following situation:
function stuff() {
try {
foreach (range(1, 100) as $i) {
yield $i;
}
}
finally {
print All done;
}
}
Does All done get printed once, or 101 times? Similarly:
function things() {
$i = 1;
try {
while (true) {
yield $i++;
}
}
finally {
print All done;
}
}
That will run indefinitely. So will All done ever print, or does that
finally become unreachable?
My own gut expectation (the answers that would surprise me the least)
would be (a) once (because the foreach is _inside_ the try block, and
the catch/finally handler is hence _outside_ the loop); and (b) the
finally{} is unreachable (assuming that loop doesn't manage to throw an
exception!) because control flow never gets to the end of the try block.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] Generators in PHP
On 2012-08-09 08:42, Nikita Popov wrote: Without parenthesis their behavior in array definitions and nested yields is ambigous: array(yield $key = $value) // can be either array((yield $key) = $value) // or array((yield $key = $value)) yield yield $key = $value; // can be either yield (yield $key) = $value; // or yield (yield $key = $value); Apart from that particular case there is the general operator precedence inclarity, e.g. yield $foo . $bar; // could be (yield $foo) . $bar; // or yield ($foo . $bar); Is this complicating yield a bit too much? All these ambiguities would go away if 'yield' had the same grammatical status as 'return' - in other words, if it were treated as a control-flow keyword rather than as an operator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error handling brainstorming
Hi!
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again, you wrap everything into try/catch on every kind of
exception possible.
Have you stopped for a moment to think this opinion through? Look at two
typical patterns of error handling. The examples below are generalized from
my file cache code. Having no cache is exceptional, because 99.999% of the
time I run this, there is cache, except the first time when there's not.
Tell me again how you using try..catch is very verbose and how you need to
supply multiple catch blocks for every kind of exception possible?
With exceptions:
try {
fileop1();
fileop2();
fileop3();
normal_actions();
} catch (IOException $e) {
exceptional_actions();
}
Without exceptions:
$valid = true;
if (fileop1() !== FALSE) {
$valid = false;
}
if ($valid fileop2() !== FALSE) {
$valid = false;
}
if ($valid fileop3() !== FALSE) {
$valid = false;
}
if ($valid) {
normal_actions();
} else {
exceptional_actions();
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
