Req #27122 [Opn->Wfx]: additional directives for declare (and other event trappers possibly)

Edit report at https://bugs.php.net/bug.php?id=27122&edit=1 ID: 27122 Updated by: requinix@php.net Reported by: nutbar at innocent dot com Summary: additional directives for declare (and other event trappers possibly) -Status: Open +Status: Wont fix Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: Irrelevant PHP Version: Irrelevant Block user comment: N Private report: N New Comment: Old request is old. This sort of thing sounds like the job for an extension and not userland PHP code, but if anyone is still interested in making this happen then check out the RFC process. https://wiki.php.net/rfc/howto Previous Comments: ------------------------------------------------------------------------ [2004-02-02 16:59:00] nutbar at innocent dot com Description: ------------ Just a low priority feature request... I thought it would be rather nice to have additional directives which the declare control structure could capture. Such events would be (for example): function entrance function exit runtime script parser status (ie, just traces what position the parser is at in any script) ... others that I might have omitted to think of... This could potentially allow a replacement of user error logging that would allow greater flexibility - we could now trace what function we're in (and keep track of) as well as which ones we exit, and also allow a line,character tracking as the PHP parser runs (or maybe even initial compiling of!) the code. This could even allow the ability to finally use user logging code to log E_PARSE errors and other stuff (maybe?). I'm not sure if I'm describing this enough as I think about what I'm thinking could be done - but hopefully whoever reads this can understand the potential benefits to being able to track various different core events aside from just "ticks". Expected result: ---------------- Just one side note - if it was made possible to trap E_PARSE (or even E_ERROR) error events, the posibility of having an error message that read like: parse error: missing '}' in /some/script.php on line 5 ultimately generated from /other/script.php on line 12 The reason would be that if you did trap a parse error or something - PHP wouldn't obviously be able to execute the failed code, but potentially could make special cases for the declare control structure (or any event trapping function) and compile that before anything else so that it could still be executed in the event of other script errors. If so, then if *that* code (the code in the declare control structure) had an error, you could get an error within an error. Hope that made sense :) If it did, the possibility of an error (or other events) trapping "loop" could arise - so maybe just ignore *this* part of the feature request (probably not feasable to try and trap such low level errors). ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=27122&edit=1