[RFC] ifsetor operator

if you make @ fetch_var it's own opcode,

• on isset() = true you do a straight return value. .. No touching
  error handler etc.. (this should be v.fast)
• on isset() = false you modify the error_handling + do the callback
  (this is slow...)
  You have effectively solved the performance issue 99% of the time....

Regards
Alan

Jason Garber wrote:

Don't forget that some users make use of set_error_handler(). This
results in a user function being called with quite a bit of parameter
data EVEN if an @ is prepended to the statement. The error level is
temporarily set to 0 for the duration of the statement.

That's why a new internal function addresses the issue so cleanly.

~Jason

At 4/17/2004 05:03 PM +0800, Alan Knowles wrote:

Yeah looks like 50% slower..!

Wouldnt it make more sense to optimize @ + fetch_var(), rather than
introduce new syntax?

Regards
Alan

Marcus Boerger wrote:

Hello Alan,
Saturday, April 17, 2004, 2:36:55 AM, you wrote:

Jason Garber wrote:

In our code, you will find many blocks looking like

$CUST_ID = (integer) (isset($_POST['CUST_ID']) ? $_POST['CUST_ID']
: 0);

so how is that different from
$CUST_ID = (integer) @$_POST['CUST_ID'];

@ is damn slow

--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com

--

--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com

Jason Garber wrote:

Don't forget that some users make use of set_error_handler(). This

Which reminds me that the documentation should be updated to reflect the
additional parameter error_types to set_error_handler. (Without it you
end up calling the user error handler lots even if you disabled
E_NOTICE for error_reporting).

Maybe the test case at
http://cschneid.com/php/php5/set_error_handler.phpt
could also be added to the distribution.

• Chris