Thank you all for inputs. There is no consensus at all, so we must go
through RFC process. I will sum up feedback and I will create the RFC this
weekend.
Kind regards,
Jorg
>
>
> This thread clearly shows that there is no consensus so I think the only
> way forward would be to create a policy RFC to make decision about this
> approach. Until then no PR introducing exception, deprecation or just plain
> warning for this sort of things should be merged.
>
>
In terms of
Hi,
On Tue, Mar 11, 2025 at 12:09 AM Jorg Sowa wrote:
> Hello everyone,
>
> I’d like to align on the approach to validating arguments for built-in
> functions (usually for flag inputs). Some ongoing discussions in PRs:
> - https://github.com/php/php-src/pull/15647
> - https://github.com/php/php-
Hi
Am 2025-03-20 17:00, schrieb Gina P. Banyard:
And again, ValueErrors are only ever added when it *easy* to check if
the condition is satisfied, and it very clearly points to a programming
error.
I still find it baffling that telling someone that the code they wrote,
even if it is decades
On Tuesday, 11 March 2025 at 21:17, Rowan Tommins [IMSoP]
wrote:
> On 11/03/2025 11:54, Gina P. Banyard wrote:
>
> > It also means that we need to do multiple passes, on the same code path,
> > resulting in somewhat of a code churn and possibly not using a common
> > abstraction.
> > Consideri
On 11/03/2025 11:54, Gina P. Banyard wrote:
It also means that we need to do *multiple* passes, on the same code path,
resulting in somewhat of a code churn and possibly not using a common
abstraction.
Considering that we didn't even have the time to properly remove some
deprecations from PHP
Am 11.03.2025 um 16:29 schrieb Christian Schneider :
> ...(if you want to be strict about warnings then just convert them to an
> exception, that's easy enough)...
Reading it back I maybe wasn't clear: I mean if you as an application developer
want to be strict then you can use an error handler
Am 11.03.2025 um 12:54 schrieb Gina P. Banyard :
> Taking the example of ext/pcntl again, if it were a standalone extension,
> having it follow semver is a way more reasonable proposition.
> Because we could just release 2 versions the same day, a x.y+1.0 introducing
> a warning, and a x+1.0.0 wh
On Tuesday, 11 March 2025 at 11:12, Rowan Tommins [IMSoP]
wrote:
>
> On 11 March 2025 10:20:52 GMT, Rob Landers rob@bottled.codes wrote:
>
> > Well, when you make it an exception, it usually gets upgraded/fixed faster
> > :)
>
>
> Not necessarily. When people see long lists of breaking chan
On 11/03/2025 06:32, Gina P. Banyard wrote:
And if not a ValueError then it should be an E_WARNING.
Raising a deprecation is frankly non-sensical.
Validation errors exist to inform the person programing that there is
an error with the call site that is preventable very easily.
If we start emitti
On 11 March 2025 10:20:52 GMT, Rob Landers wrote:
>Well, when you make it an exception, it usually gets upgraded/fixed faster :)
Not necessarily. When people see long lists of breaking changes in a release,
they may just put off upgrading / marking the library compatible.
I think we should
On Tue, Mar 11, 2025, at 10:07, Christian Schneider wrote:
> Am 11.03.2025 um 07:32 schrieb Gina P. Banyard :
> > On Monday, 10 March 2025 at 23:07, Jorg Sowa wrote:
> >> I’d like to align on the approach to validating arguments for built-in
> >> functions (usually for flag inputs). Some ongoing
Am 11.03.2025 um 07:32 schrieb Gina P. Banyard :
> On Monday, 10 March 2025 at 23:07, Jorg Sowa wrote:
>> I’d like to align on the approach to validating arguments for built-in
>> functions (usually for flag inputs). Some ongoing discussions in PRs:
>> - https://github.com/php/php-src/pull/15647
On Monday, 10 March 2025 at 23:07, Jorg Sowa wrote:
> Hello everyone,
>
> I’d like to align on the approach to validating arguments for built-in
> functions (usually for flag inputs). Some ongoing discussions in PRs:
> - https://github.com/php/php-src/pull/15647
> - https://github.com/php/php-sr
My vote is on straight to ValueError without RFC. Deprecations should
only be limited to meaningful changes in functionality, not fixing
bugs or undefined behaviour. Lack of argument validation is not a
behaviour users would have relied on in past.
Hello everyone,
I’d like to align on the approach to validating arguments for built-in
functions (usually for flag inputs). Some ongoing discussions in PRs:
- https://github.com/php/php-src/pull/15647
- https://github.com/php/php-src/pull/15883
- https://github.com/php/php-src/pull/17859
In some
16 matches
Mail list logo
