Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const expressions
May 29, 2022 11:55:56 AM Michał Marcin Brzuchalski : > > > niedz., 29 maj 2022 o 18:24 Larry Garfield > napisał(a): >> On Sat, May 28, 2022, at 4:44 AM, Ilija Tovilo wrote: >>> 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. >>> >>> Regards, >>> Ilija >> >> The enum-in-attribute use case came up recently in Symfony. I'm in favor >> and the RFC looks good to me. > > Personally, I'd start the discussion on > https://wiki.php.net/rfc/object_keys_in_arrays instead as this might solve > the need for > fetching property in constant expressions. > > Cheers, > Michał Marcin Brzuchalski Objects as array keys would not help with the attribute use case. It may be useful on its own, but it does not obviate the need for this rfc. --Larry Garfield
Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const expressions
On Sat, May 28, 2022 at 11:44 AM Ilija Tovilo wrote: > 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. > > Regards, > Ilija > This looks like a reasonable addition. Could there be any expectation that if -> works, ?-> does as well? Regards, Nikita
Re: [PHP-DEV] [RFC][Under discussion] Create a global login system for php.net
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 OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [Discussion] Expand deprecation notice scope for partially supported callables
Hi Dan,
On 29-5-2022 17:34, Dan Ackroyd wrote:
Actually, I've just realised there is an error in the code in the RFC,
which might be based on a misconception caused by how terrible
callables are. In the code:
if (is_callable('static::methodName')) {
// For valid callbacks, this call will be executed in PHP 8.x,
// but will no longer execute in PHP 9.x.
static::methodName();
}
The string based callable 'static::methodName' is not equivalent to
the syntax* based callable static::methodName().
...
This is actually not an error in the RFC, but an anonymized code sample
based on real-life code patterns found in popular packages.
While the syntaxes are not technically equivalent, functionally, they
yield the same result, which is why this code pattern is not uncommon.
It is exactly this type of code pattern - and the associated
misconception leading to this code existing in real life code bases -,
which started the initial discussion about the lack of deprecation
notices for is_callable() and led to this RFC.
for the practical implications of fixing the deprecations,
there is no difference between the two.
People don't have to fix their code. Deprecations can sit there for as
long as the user likes. If a company decides that paying RedHat for
long term PHP 8.2 support, then they may choose to never fix these
deprecation warning and just silence them instead.
Which leads to a difference of, the deprecation notice when checking
with is_callable and using the callable can be suppressed reasonably
easily:
@is_callable('static::methodName')
@call_user_func('static::methodName', []);
And that's a reasonably sane** thing to do. But the deprecation notice
when passing callables around could happen across many pieces of code,
and there's not a good way of suppressing them, unless you just turn
off deprecation notices entirely.
With the deprecation notice where a user is checking, and a
deprecation notice where it is used, I don't see any value in extra
deprecation notices where the callable is being passed around.
IMO that's a false argument as deprecation notices are not intended for
people who don't intend to upgrade their PHP version.
If there is no intention to upgrade to PHP 9.0, the much simpler
solution would be to set `error_reporting` to `E_ALL & ~E_DEPRECATED`.
Alternatively, a custom error handling could be registered which filters
out all, or only a selection of, deprecation notices.
Deprecation notices are for those people who _do_ want to upgrade to PHP
9.0 once it comes out and want to prepare their code base to be ready.
And for those people, the `callable` type not throwing a deprecation
notices means that for the "registered, but rarely called" callables,
they will go from _nothing_ to a Fatal Error once PHP 9.0 comes round,
which is exactly what this RFC tries to address.
Either way, I do agree that this potential objection should be heard, so
I have added an extra section to the "Discussion" section of the RFC in
which I have summarized our discussion (so far) about this:
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices#these_additional_deprecation_notices_will_be_very_noisy
do you still feel that splitting the vote in two is the best way to go ?
Yes, due to the deprecation notices on type-checks when calling
functions have a higher pain-to-utility that in the is_callable check.
Fair enough, I will split the vote and have updated the RFC to show this.
I also like the deprecation notice on is_callable, as that notice will
be 'closer' to where the bad callable is coming from, so would be
easier to reason about. There's also a rare edge-cases where someone
has a callable that is only called in emergencies (like a disk running
out of space) and so might not have that happen for months. Having the
deprecation on is_callable would help those edge-cases a little.
Just pointing out, the same thing can happen with the `callable` type -
a callable being registered for an emergency (like a disk running out of
space), but not being called for months. This example edge case is not
limited to `is_callable()`.
I hope the RFC update addresses your concerns sufficiently. If there are
no further objections, I will open the vote.
Smile,
Juliette
Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const expressions
Hi Michał > Personally, I'd start the discussion on > https://wiki.php.net/rfc/object_keys_in_arrays instead as this might solve > the need for > fetching property in constant expressions. As mentioned in the RFC, supporting objects as array keys requires much larger changes in the engine, and also breaks userland assumptions that array keys can only be of type int|string which means array functions need to handle object keys accordingly. For comparison, the "object keys in arrays" RFC is incomplete (changes for most extensions are missing) and contains ~1300 LOC added and ~1300 removed. All 3rd party PHP extensions would also need to be updated accordingly. The implementation for this RFC is feature complete and is at ~160 LOC added. I actually think both of these RFCs are worthwhile, but since this one is simpler and does not break userland assumptions it might solve the problem in a good enough way. --- HI Alexandru > I feel that the RFC should be named "Fetch properties in initializers", in > sync with https://wiki.php.net/rfc/new_in_initializers > You explain what "constant expression" means but I feel that using > "initialize expression" would be more clear. > From what I understand, "constant expression" is named like this because > until PHP 8.1 it really was a constant. > And of course because internally this is how the functions in code are named: > - zend_is_allowed_in_const_expr > - zend_compile_const_expr > - zend_const_expr_to_zval > > It's unclear how easy it would be to rename them to init_expr instead of > const_expr > but it might be worth it if we consider that "initialize expression" is a > better name. Note that we also use the term constant expression in some error messages. https://3v4l.org/d2WnS I intentionally picked a static variable to show that it's not restricted to consts. But I'm not attached to the term, if it's clearer for other people I'm happy to switch to "initializer". Regards, Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const expressions
On Sat, May 28, 2022 at 12:44 PM Ilija Tovilo wrote: > 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. > I feel that the RFC should be named "Fetch properties in initializers", in sync with https://wiki.php.net/rfc/new_in_initializers You explain what "constant expression" means but I feel that using "initialize expression" would be more clear. >From what I understand, "constant expression" is named like this because until PHP 8.1 it really was a constant. And of course because internally this is how the functions in code are named: - zend_is_allowed_in_const_expr - zend_compile_const_expr - zend_const_expr_to_zval It's unclear how easy it would be to rename them to init_expr instead of const_expr but it might be worth it if we consider that "initialize expression" is a better name. The RFC looks great and clear. Regards, Alex > > Regards, > Ilija > > -- > 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
On Sun, 29 May 2022 at 16:34, Dan Ackroyd wrote: > > *an incorrect name* Apologies for writing your name incorrectly. That should of course have been addressed to Juliette. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const expressions
niedz., 29 maj 2022 o 18:24 Larry Garfield napisał(a): > On Sat, May 28, 2022, at 4:44 AM, Ilija Tovilo wrote: > > 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. > > > > Regards, > > Ilija > > The enum-in-attribute use case came up recently in Symfony. I'm in favor > and the RFC looks good to me. > Personally, I'd start the discussion on https://wiki.php.net/rfc/object_keys_in_arrays instead as this might solve the need for fetching property in constant expressions. Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const expressions
On Sat, May 28, 2022, at 4:44 AM, Ilija Tovilo wrote: > 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. > > Regards, > Ilija The enum-in-attribute use case came up recently in Symfony. I'm in favor and the RFC looks good to me. --Larry Garfield -- 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 Julie,
On Sat, 28 May 2022 at 09:22, Juliette Reinders Folmer
wrote:
>
> I admit, I puzzled over this for a little and wanted to take the time to
> respond properly before opening the vote, so I'm delaying the start of the
> vote until beginning of the upcoming week.
Cool.
Actually, I've just realised there is an error in the code in the RFC,
which might be based on a misconception caused by how terrible
callables are. In the code:
if (is_callable('static::methodName')) {
// For valid callbacks, this call will be executed in PHP 8.x,
// but will no longer execute in PHP 9.x.
static::methodName();
}
The string based callable 'static::methodName' is not equivalent to
the syntax* based callable static::methodName().
Using the string version consistently, the equivalent code would be:
if (is_callable('static::methodName')) {
call_user_func('static::methodName', []);
}
which for 8.2 gives the message 'Deprecated: Use of "static" in
callables is deprecated in %s on line %d'. btw trying to call
('static::methodName')(); gives the error message 'Uncaught Error:
Class "static" not found in %s:%d' which is part of the consistency
cleanup done by the previous RFC.
Using the syntax version, the equivalent code that would compatible
with PHP < 8.1
if (is_callable(static::class . '::methodName')) {
static::methodName();
}
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();
}
Passing the callable round by getting the closure from
static::methodName(...) is probably the safest way of referencing this
type of callable.
None of the syntax based ways of referring to the callable are
deprecated or going to be removed in the foreseeable future.
> for the practical implications of fixing the deprecations,
> there is no difference between the two.
People don't have to fix their code. Deprecations can sit there for as
long as the user likes. If a company decides that paying RedHat for
long term PHP 8.2 support, then they may choose to never fix these
deprecation warning and just silence them instead.
Which leads to a difference of, the deprecation notice when checking
with is_callable and using the callable can be suppressed reasonably
easily:
@is_callable('static::methodName')
@call_user_func('static::methodName', []);
And that's a reasonably sane** thing to do. But the deprecation notice
when passing callables around could happen across many pieces of code,
and there's not a good way of suppressing them, unless you just turn
off deprecation notices entirely.
With the deprecation notice where a user is checking, and a
deprecation notice where it is used, I don't see any value in extra
deprecation notices where the callable is being passed around.
> do you still feel that splitting the vote in two is the best way to go ?
Yes, due to the deprecation notices on type-checks when calling
functions have a higher pain-to-utility that in the is_callable check.
Just guessing, I think the previous RFC thought a deprecation notice
on is_callable isn't needed, as there will be a deprecation notice
when the callable is used. But that probably didn't account for people
being able to mix'n'match callable syntaxes, where is is_callable
check, and the actual use of the callable, are not the same callable.
I also like the deprecation notice on is_callable, as that notice will
be 'closer' to where the bad callable is coming from, so would be
easier to reason about. There's also a rare edge-cases where someone
has a callable that is only called in emergencies (like a disk running
out of space) and so might not have that happen for months. Having the
deprecation on is_callable would help those edge-cases a little.
cheers
Dan
Ack
* Is "syntax based callable" the right name? Better suggestions welcome.
** compared to some stuff I've seen/written.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
AW: [PHP-DEV] [RFC][Under discussion] Create a global login system for php.net
Hi Andreas > In addition I would say that we can assume the edit.php.net to be dead after > we moved documentation from SVN to git. So that is awesome as that > means "one down" and we couldn't already find someone to modify > edit.php.net to work with git instead of SVN. So that's great news! Good point. Will add this to my RFC. I was not aware of this. > GitHub is a company based in the US and therefore bound to US law. That > already means that people from certain countries can not (easily) collaborate > and are therefore also excluded from contributing in any way to PHP[1]. In > addition to those regulations directly by GitHub some countries are blocking > access to GitHub on their own account which means that Developers from > Russia or China will have a harder time contributing to PHP due to the fact > that they are not able to login into any system. > > Are we aware of that? I think that's an issue many people had when PHP moved to GitHub. But now development is already on GitHub, so in my opinion there isn't a big issue with that (beside of course that they can't participate in general). For your concerns regarding human resources, I would do everything needed to bring such a system to existence. Best regards Aaron Junker
Re: [PHP-DEV] [RFC][Under discussion] Create a global login system for php.net
Hey All. On 28.05.22 11:53, Aaron Junker wrote: Hi all, I would like to start the discussion on my RFC for creating a global login system on php.net: https://wiki.php.net/rfc/global_login. When you have feedback to a specific point of the RFC, please use the corresponding number used in the RFC. I do have my issues with the general RFC. The idea to have one login system to all parts of the PHP internals ecosystem seems tempting for sure. But as you pointed out in the introduction, there are 9 different services - partly rather old ones - that would require some work to make SSO work. Some of them we have control over, some of them we do not (as those are external applications that we are using. Fiddling with their sourcecode might be possible but will leave us more or less unable to update the tools) So moving those applications that we have control over towards SSO will bind resources. And not only now, but also in the future as those tools might need updates as well. Resources though, espechialy for infrastructure, are a very rare good! In addition I would say that we can assume the edit.php.net to be dead after we moved documentation from SVN to git. So that is awesome as that means "one down" and we couldn't already find someone to modify edit.php.net to work with git instead of SVN. So that's great news! 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. And there might even be more than those. So what I'm trying to bring across here is that this task will bind a lot of resources with a gain that I'm not sure is worth the effort. And instead of binding people working on resources that improve the life of a few (those working on these quirky systems) I'd rather see those resources spent where they improve the life of all PHP-Developers. Like improving the docs, triaging bugs, answering questions on StackOverflow/Room11/PHPC/Whatever else there is. In addition to that I would like to raise my concerns over using GitHub login for everything (Topic 1.2). GitHub is a company based in the US and therefore bound to US law. That already means that people from certain countries can not (easily) collaborate and are therefore also excluded from contributing in any way to PHP[1]. In addition to those regulations directly by GitHub some countries are blocking access to GitHub on their own account which means that Developers from Russia or China will have a harder time contributing to PHP due to the fact that they are not able to login into any system. Are we aware of that? On the other hand maintaining our own SSO-Solution will bind even more resources... See above. In addition: The number of different logins is usually rather small per person. And keeping track of the different systems and passwords via a PasswordManager should solve most of the day-to-day hassle. Having a central place though to document the hassle would be a very helpful addition to the PHP ecosystem! My 0.02€ Cheers Andreas - The one having struggled for some years with just *one* infra-change. [1] https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls#on-which-countries-and-territories-are-us-government-sanctions-applied Best regards Aaron Junker -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ OpenPGP_0xA8D5437ECE724FE5.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[PHP-DEV] [RFC] [VOTE] Add true as type
Hello internals, I've opened the vote for the Add true as type RFC. https://wiki.php.net/rfc/true-type It will run for two weeks and will close on the 12th of June 2022. Best regards, George P. Banyard
