Re: [PHP-DEV] deprecation of set_error_level() callback $errcontext argument
> On Tue, Oct 2, 2018 at 11:37 PM Rowan Collins wrote: > >> While I can understand the desire to have debugging feature built into >> the language "out of the box", it may be best left to extensions which >> can capture the information to a log or wherever without providing the >> full flexibility of the language to interact with it. > > I think, since the language *did* provide this "out of the box", it's sort of > odd to deprecate a feature that is being used by a popular product - the > Sentry PHP package has 8 million downloads, and PHP developers rely > on this in production to help them fix bugs. Seems pretty important? > > And an extension isn't really an acceptable alternative to someone who > was offering a product that "just worked". > > For example, rather than removing this feature, might it be possible to > deeply clone the variables and provide backwards compatibility in that > manner? I doubt that anyone is counting on introducing side-effects via > an error-handler, but surely it's not uncommon for error-aggregators and > loggers to rely on this information being available? > According to the sentry people here https://github.com/getsentry/sentry-php/issues/662#issuecomment-426550180 they don't actually use that anymore: > I've done a little bit of digging here and there, and luckily this seems a > non-issue for us! > In the 2.0 branch that argument is not used: -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] deprecation of set_error_level() callback $errcontext argument
On Tue, Oct 2, 2018 at 11:37 PM Rowan Collins wrote: > While I can understand the desire to have debugging feature built into > the language "out of the box", it may be best left to extensions which > can capture the information to a log or wherever without providing the > full flexibility of the language to interact with it. I think, since the language *did* provide this "out of the box", it's sort of odd to deprecate a feature that is being used by a popular product - the Sentry PHP package has 8 million downloads, and PHP developers rely on this in production to help them fix bugs. Seems pretty important? And an extension isn't really an acceptable alternative to someone who was offering a product that "just worked". For example, rather than removing this feature, might it be possible to deeply clone the variables and provide backwards compatibility in that manner? I doubt that anyone is counting on introducing side-effects via an error-handler, but surely it's not uncommon for error-aggregators and loggers to rely on this information being available? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC Result: Make the hash extension always available
Greetings hackers I'm happy to announce that the RFC "Always available hash extension" have been accepted with a 30-0 vote. I apologies for the initial poorly written date in the voting announcement email. Thank you all for voting! -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
