Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116999
MIME-Version: 1.0
References: <ded42b3e-3149-1192-0f86-07715fcb7a3e@woltlab.com>
 <CA+kxMuTVMeqVN1UFwau3eaVgLa2DKRKaErzSdFCKLw9v066mVQ@mail.gmail.com> <01c3082c-c69d-7337-64f7-8314ade305a2@woltlab.com>
In-Reply-To: <01c3082c-c69d-7337-64f7-8314ade305a2@woltlab.com>
Date: Mon, 7 Feb 2022 16:36:27 +0000
Message-ID: <CA+kxMuQnT137FHe5miAmNgv-ED+WeN=WFEkbe-RRXyKn8zzorQ@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus=2C_WoltLab_GmbH?= <duesterhus@woltlab.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces
From: Danack@basereality.com (Dan Ackroyd)

On Tue, 11 Jan 2022 at 09:11, Tim D=C3=BCsterhus, WoltLab GmbH
<duesterhus@woltlab.com> wrote:
>
> So basically all the other languages I researched do not provide
> arguments within back traces.

Uh, that kind of suggests that providing arguments at all is a
mistake, and that removing could be the way to go. I mean other than
everyone complaining about the BC break.

An awkward question; why is this hard-coding of the behaviour
dependent on a new attribute the correct thing to do?

PHP allows people to set_error_handler() to process errors how they
like. Conceiveably, allowing users to set a custom function to redact
data from stack traces would allow users to inspect and redact the
parameters however they like. Why is adding a special attribute that
is recognised by the PHP engine itself the right thing to do?

To be clear, I can think of at least two reasons. But also, I think
every attribute that is proposed to be added to PHP core, needs to
have the reasons why it's the right thing to do listed. If nothing
else, it will help to reject attributes in the future if they don't
have the same strong justifications.

cheers
Dan
Ack