Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59360
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F7E2F1B.2030109@sugarcrm.com>
References: <CADqTB_i0yEgnqiOVbRLteA4rrdTuH1x-wNyEi2wQf0XnvrY9Hg@mail.gmail.com>
 <2FD77C3003DC4656BCF6309B097DD978@gmail.com> <CADqTB_iMYzGY2h6xha5mu1epjeZZPWoWegu6g1TgCcayEMrAxw@mail.gmail.com>
 <CAAyV7nEa9yoagqFYsARda52QCSudjSS0dboEo8j2oOE6M0yHJw@mail.gmail.com>
 <4F7E1FB8.7020108@sugarcrm.com> <CA+Ky_uManhYtrcXys43bWifhMroF=QyUktS12No=e4J_7OJ2Fw@mail.gmail.com>
 <4F7E2F1B.2030109@sugarcrm.com>
Date: Thu, 5 Apr 2012 17:51:48 -0700
Message-ID: <CA+Ky_uMW8ds=83xWkZpCAo4N6txkYj4h8PKYhosEV8tKjN7JiA@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf30334a051d747d04bcf81278
Subject: Re: [PHP-DEV] resume after exception
From: ww.galen@gmail.com (Galen Wright-Watson)

--20cf30334a051d747d04bcf81278
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 5, 2012 at 4:47 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

>
> However, in general, thinking about more complex flow control structures
> in fine. Just there's no reason to get exceptions mixed into it.
>
> Agreed. While restarting and resuming after exceptions could be useful,
and a condition signaling control structure could also be useful, the two
should be distinguished at the language level (even if they were
implemented using the same mechanism under the hood).

So, what do people think of some sort of retry mechanism for exceptions?
What about a (separate) condition signaling control structure? What about
serializable continuations, allowing for resuming execution in a separate
request?

CPS offers an alternative to the first two. As much as the idea appeals to
me, retries seem less useful to me in PHP than in other languages unless
(as Rasmus initially suggested) execution were serializable, which I
suspect would be a heavy feature.

Serializable continuations would require the most work to implement using
PHP if it's never supported by the language itself. I suspect that
serializable continuations will be space-inefficient no matter where
they're implemented. Web continuations may not be common practice now, but
part of the reason for that may be lack of support. It could become more
popular if it were available. On the other hand, PHP's heritage as a
templating language means serializable continuations may be just as much a
problem as "die" or "exit" is, as they can result in invalid HTML.

--20cf30334a051d747d04bcf81278--