# [RFC] ifsetor operator - Thread: https://externals.io/message/9317 - Original archive: https://news-web.php.net/php.internals/9317 - Started by Jason Garber on 2004-04-17T09:06:55+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #9317 — Jason Garber — 2004-04-17T09:06:55+00:00 URL: https://externals.io/message/9317#9317 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: > > […] > > >-- >Can you help out? >Need Consulting Services or Know of a Job? >http://www.akbkhome.com --- ## #9319 — Alan Knowles — 2004-04-17T09:20:12+00:00 URL: https://externals.io/message/9317#9319 · In reply to: #9317 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: > > > […] > > -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com --- ## #9320 — Wez Furlong — 2004-04-17T09:24:53+00:00 URL: https://externals.io/message/9317#9320 · In reply to: #9319 This doesn't help anything in the case where the thing isn't set and you don't care that it isn't set, and don't want to call the error handler at all. --Wez. ----- Original Message ----- From: "Alan Knowles" To: "Jason Garber" ; Sent: Saturday, April 17, 2004 10:20 AM Subject: Re: [PHP-DEV] Re: [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 --- ## #9325 — Christian Schneider — 2004-04-17T12:00:08+00:00 URL: https://externals.io/message/9317#9325 · In reply to: #9317 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 --- ## #9326 — Christian Schneider — 2004-04-17T12:17:21+00:00 URL: https://externals.io/message/9317#9326 · In reply to: #9325 Christian Schneider wrote: > Which reminds me that the documentation should be updated to reflect the > additional parameter error_types to set_error_handler. (Without it you Oops, fell into the same trap again. My browser is set to german so I automatically saw the german version of the page which is outdated. Quickly changed my browser settings to not make the same mistake again :-) Which brings me back to yet another point: The various languages of the documentation should state when they are outdated in respect to the english version. - Chris --- ## #9327 — Rasmus Lerdorf — 2004-04-17T14:53:32+00:00 URL: https://externals.io/message/9317#9327 · In reply to: #9326 > Christian Schneider wrote: > > […] > > Oops, fell into the same trap again. My browser is set to german so I > automatically saw the german version of the page which is outdated. > Quickly changed my browser settings to not make the same mistake again :-) > > Which brings me back to yet another point: The various languages of the > documentation should state when they are outdated in respect to the > english version. I wrote a script years ago that figured this out and showed a little report card for each translation. I think someone took that and ran with it, but I have no idea where the current version lives today. -Rasmus --- ## #9328 — Gabor Hojtsy — 2004-04-17T15:59:23+00:00 URL: https://externals.io/message/9317#9328 · In reply to: #9327 Revision checking is available in the php documentation build system perfectly, but it is not (yet) exposed to the end users (outdated translations are not marked). This will be one of the things solved by livedocs, sometime in the future. Goba > > […] > > > I wrote a script years ago that figured this out and showed a little > report card for each translation. I think someone took that and ran with > it, but I have no idea where the current version lives today. > > -Rasmus