Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const expressions
Le 28 mai 2022 11:44:13 GMT+02:00, Ilija Tovilo a
écrit :
>Hi everyone
>
>I'd like to start a discussion on a simple RFC to allow fetching
>properties in constant expressions.
>https://wiki.php.net/rfc/fetch_property_in_const_expressions
>
>The RFC proposes adding support for fetching properties in constant
>expressions using the -> operator. I'm looking forward to your
>feedback.
It is not clear to me why this allows using -> on enums but not on other
objects.
Can you clarify why the following is not allowed:
var;
static $staticobj = new Thing();
function f($p = self::$staticobj->var) {}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: NULL Coercion Consistency
On Mon, May 30, 2022 at 4:59 PM Rowan Tommins wrote: > > The actual code in this case ended up in a generic routine that used > isset() to choose which SQL to generate. An empty string would generate > a WHERE clause that matched zero rows, but a null would omit the WHERE > clause entirely, and match *all* rows. So an extra pre-validation on the > string format might be useful for debugging, but wouldn't result in > materially different results. Maybe the routine could use e.g. array_key_exists() rather than isset()? (anyway, sometimes you *actually* want isset() null behavior, or use a null default for a parameter as a "not passed" argument...) > That's actually an interesting observation. It's probably quite common > to treat empty strings as null when going from input to storage; and to > treat null as empty string when retrieving again. Importantly, databases > generally *don't* treat them as equivalent, Yeah, I only know Oracle to do something as... "clever" as storing an empty VARCHAR '' as NULL (for "optimization" IIRC) -_- > so forgetting that > translation can be a real cause of bugs. I often advocate for string > columns in databases to allow either null or empty string, but not both > (by adding a check constraint), so that such bugs are caught earlier. Same (sometimes you have no choice but allow NULL, e.g. an optional foreign key, but the referenced primary key is not nullable and should generally also reject '') -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: NULL Coercion Consistency
On 30/05/2022 15:04, Guilliam Xavier wrote:
For this specific example, shouldn't it rather [already] be like this anyway?
function getByIdentifier(string $identifier) {
if ( $identifier === '' ) {
throw new InvalidArgumentException("Empty identifier");
}
// ...
}
(but I guess you could find actual examples where an empty string is
"valid" and null is not, indeed)
The actual code in this case ended up in a generic routine that used
isset() to choose which SQL to generate. An empty string would generate
a WHERE clause that matched zero rows, but a null would omit the WHERE
clause entirely, and match *all* rows. So an extra pre-validation on the
string format might be useful for debugging, but wouldn't result in
materially different results.
I'm just worried to see people rather disabling deprecation notices
(via error_reporting, or a custom error handler, or even patching
PHP's source and recompiling their own) than "fixing" the code
(granted, that's not specific to*this* RFC, but somewhat "highlighted" here)
Indeed, I think we have a general problem with how deprecations are
communicated and acted on in general. I have been thinking about how to
improve that, other than "never change anything" or "never warn people
we're going to change anything", and will try to write up my ideas soon.
function null_to_empty_string(?string $string_or_null): string
{ return $string_or_null === null ? '' : $string_or_null; }
(but also its "opposite" empty_string_to_null(string $string): ?string)
That's actually an interesting observation. It's probably quite common
to treat empty strings as null when going from input to storage; and to
treat null as empty string when retrieving again. Importantly, databases
generally *don't* treat them as equivalent, so forgetting that
translation can be a real cause of bugs. I often advocate for string
columns in databases to allow either null or empty string, but not both
(by adding a check constraint), so that such bugs are caught earlier.
To go back to Craig's favourite example, that could be a genuine problem
caused by passing null to htmlspecialchars() - if we intended that null
to be stored as such in the database, we've silently converted it into a
non-equivalent empty string. (Yes, escaping should be done on output not
input, but it's not completely infeasible that that combination might
happen.)
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables
Hi Dan, just an error in this part:
> Or if support for less than PHP 8.1 can be dropped, using the first
> class callable syntax
> https://wiki.php.net/rfc/first_class_callable_syntax :
>
> if (is_callable(static::methodName(...))) {
> static::methodName();
> }
>
> or
>
> $fn = static::methodName(...);
> if (is_callable($fn)) {
> $fn();
> }
This throws an Error on `static::methodName(...)` [if not callable],
before even passing it to `is_callable()`: https://3v4l.org/m29BK
And yes, code should probably better use a same variable for both the
check and the call, but that could also degrade DX (IDE
autocompletion, static analysis) especially if calling with
arguments...
(the other parts of your message have been answered by Juliette)
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: NULL Coercion Consistency
On Tue, May 24, 2022 at 10:47 AM Rowan Tommins wrote:
>
> As an anecdote, I was recently working on a bug involving nulls causing
> unintended behaviour in an API. As part of the clean-up, I changed a
> function signature from getByIdentifer($identifier) to
> getByIdentifer(string $identifier), and during testing, got an error
> because I'd missed a scenario where null was passed. This was a good
> result - it prevented the broken behaviour and alerted me to the case
> that needed fixing. If the parameter had instead been silently coerced
> to an empty string, I would have got neither an error nor the original
> null behaviour, causing a new bug that might have taken much longer to
> track down.
>
> If your RFC as drafted was implemented, I could only have achieved the
> desired check by turning on strict_types=1 for whole sections of the
> application, which would probably require dozens of other fixes, or
> writing an ugly manual check:
>
> function getByIdentifier(?string $identifier) {
> if ( $identifier === null ) {
> throw new TypeError("Function doesn't actually accept nulls");
> }
> // ...
> }
For this specific example, shouldn't it rather [already] be like this anyway?
function getByIdentifier(string $identifier) {
if ( $identifier === '' ) {
throw new InvalidArgumentException("Empty identifier");
}
// ...
}
(but I guess you could find actual examples where an empty string is
"valid" and null is not, indeed)
> As I have said previously, I share your concern about the impact of the
> currently planned change, but I don't think loosening the existing type
> rules on user-defined functions is a good solution.
I agree the "issue" looks like different PoV of benefit VS cost, plus
the reticence about going back on the general trend of "more
strictness" (even with strict_types=0).
I'm just worried to see people rather disabling deprecation notices
(via error_reporting, or a custom error handler, or even patching
PHP's source and recompiling their own) than "fixing" the code
(granted, that's not specific to *this* RFC, but somewhat "highlighted" here)
FWIW, to avoid the "risks" of `expr ?? ''` (possibly hiding undefined)
and `(string)expr` / `strval(expr)` (potentially casting "too much"
without errors), I've already seen custom functions like
function null_to_empty_string(?string $string_or_null): string
{ return $string_or_null === null ? '' : $string_or_null; }
(but also its "opposite" empty_string_to_null(string $string): ?string)
Regards,
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Under discussion] Create a global login system for php.net
On Sun, May 29, 2022 at 10:09 PM Ben Ramsey wrote: > > On 5/29/22 09:57, Andreas Heigl wrote: > > But the bad news is, that there is also the colobus system which powers > > the NNTP-server backend that a number of people use to interact with the > > mailing-list. Which also has an authentication and would therefore need > > to be switched. So we are back at 9 services. And we switched one that > > is completely under our control to one that isn't as we are merely using > > a (rather old by now) service. > > I've looked into colobus a fair amount, and it does not use > authentication itself. It accepts requests to post to newgroups, but > then it appears to primarily act as a proxy for ezmlm, which has it's > own form of authentication, and we're not going to be able to tie the > ezmlm authentication to GitHub. > > -- > Cheers, > Ben There's also the OAuth Proxy project: https://oauth2-proxy.github.io/oauth2-proxy/docs/features/endpoints which allows you to use some baked-in features of nginx in order to provide unauthenticated/legacy services with protection and appropriate authentication headers: https://nginx.org/en/docs/http/ngx_http_auth_request_module.html. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
