====== PHP RFC: Ripples ======
  * Version: 0.1
  * Date: 2013-10-30
  * Author: Joe Watkins, krakjoe@php.net
  * Status: Draft
  * First Published at: http://wiki.php.net/rfc/ripples

===== Introduction =====

In the world of programming, there are basically two ways to deal with errors, and one to have those errors affect the flow of execution.

One, is not very many. There is a problem in a world where there is only one way to do anything at all, but in particular it causes a problem for us:

<code php>
$socket->connect();

try {
   while ($socket->connected()) {
     try {
       $data = $socket->read();
       
       try {
         while (($buffer = $transcoder->transcode($data))) {
           
         }
         
       } catch (DataDecodeException $dde) {
          
       }
     } catch (SocketReadException $sre) {
     
     }
   }
} catch (SocketDisconnectedException $sde) {

}
</code>

This is, horrible. It's horrible because the flow of execution is fragmented and broken. None of us design code to be fragmented or broken, but we cannot deny that "fragmented and broken" is a perfectly valid description of the code above. 

//Questions//: 
  - what is an exception ? 
  - what does it signify ? 

//Answers//:
  - an exception encapsulates or describes an error
  - an exception signifies the the flow of execution must be //broken//, and that the vm must jump to another //fragment// of code in order to continue execution. 

So, that's exceptions dealt with, //they create fragmented and broken flow.//

Warnings have an even bigger problem in that they do not affect your code //at all//; you only see them during development, once deployed your code is not even aware they have been raised.

Our code can only detect such conditions deductively by extrapolating it from the current state of the program; inferring such conditions exist by executing a considerable amount of logic.

What constitutes a warning currently, does not necessarily constitute an exception; take the arbitrary example of a socket timeout, such conditions do not necessarily mean that the flow of execution is broken, the problem may well be temporary, or rectifiable //in code//. 

So, that's warnings, they don't affect anything in any useful way and cause us to undertake more work than is necessary.

===== Proposal =====

A //Ripple// will encapsulate or describe conditions on the scale from warning to exception, a //dam// will deal with those conditions and, if no exceptions/returns/exits [unsure of these conditions] occur while dealing with them, allow the vm to execute the block that dropped the //Ripple// again.

<code php>
try {
   while ($socket->connected()) {
     try {
       $data = $socket->read();
       
       try {
         while (($buffer = $transcoder->transcode($data))) {
 
         }
 
       } catch (DataDecodeException $dde) {
          /* this is exceptional */
          /* nothing can be done to recover execution */
       }
     } dam (SocketReadRipple $sr) {
 
     }
   }
} dam (SocketDisconnectRipple $sd) {
 
}
</code>

Dropping ripples may look like:

<code php>
/* ... */
drop new SocketReadRipple($this);
/* ... */
</code>

The flow of this program could be described as fragmented, but it is //not// broken, execution //flows// from one block to another in a non-linear way.

We throw exceptions to be caught, unconditionally altering the flow of execution; we can drop ripples to be dammed, allowing execution to recover.
===== Backward Incompatible Changes =====

I have no idea ...

===== Proposed PHP Version(s) =====

I think 6 ?

===== SAPIs Impacted =====

N/A 

===== Impact to Existing Extensions =====

N/A

===== New Constants =====

N/A

===== php.ini Defaults =====

N/A

===== Open Issues =====

All

===== Unaffected PHP Functionality =====

All

===== Future Scope =====

Do we have in ripples a viable replacement for warnings and notices ?

===== Preempted Opinions =====

  * You are crazy
  * Write it and we will come
  * I love warnings and notices and don't see the problem

===== Patches and Tests =====

Oh no, not yet. Let us discuss the idea first.