Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
On 23 June 2022 17:48:57 BST, Levi Morrison via internals wrote: >IMO, this should mirror the low-level curl url API very directly. The >basis of my opinion is that we do not own libcurl; we are merely >adapting it for use in PHP. We cannot anticipate changes in their >design, nor do we have authority to do so if we feel something should >change. Touching it as little as possible makes it easier to track >upstream changes, etc. > >Based on that, I think the naming should be closer to libcurl.: > - CurlUrl::URL_ENCODE should be CurlUrl::URLENCODE > - CurlUrl::URL_DECODE should be CurlUrl::URLDECODE > >And so on, only differing if necessary because something is a reserved >word. The API should be as exact as possible to what libcurl provides. >The "helpers" getHost, getPassword, etc should be removed and should >expose `curl_url_get` more directly. > >Of course, it should be object based instead of resource based, but that's it. > >A nicer API can be built on top of it, but I don't think that's the >role this particular API should play. For the record, I disagree with literally everything you've said here. PHP indeed does not own libcurl, and nor does libcurl own PHP. We are targeting a different audience, and have a different set of facilities available to us. We have our own documentation, so there is no reason a user of PHP should know or care what the underlying implementation looks like, any more than they should know how the memory allocation works. If the underlying library adds a feature, it will be as easy to add a new method as a new constant. If the underlying library changes behaviour, we will want to make our own decision on whether that meets our compatibility policy, and whether to emulate the older behaviour (or indeed emulate the newer behaviour on systems with an older library). Twenty years ago, maybe PHP programmers were used to it being a veneer over C. I don't think that is or should be the expectation today, unless you're using FFI. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
On Tue, Jun 21, 2022 at 10:38 PM Pierrick Charron wrote: > > Hi, > > Following our discussions we had on the subject of the new Curl URL API, > and other curl improvements. I decided to only focus on adding the new Curl > URL API and put aside all other improvements. Here is the RFC that reflects > our current conversations. > > https://wiki.php.net/rfc/curl-url-api > > Feel free to give any feedback, concern or support :-) > > Regards, > Pierrick IMO, this should mirror the low-level curl url API very directly. The basis of my opinion is that we do not own libcurl; we are merely adapting it for use in PHP. We cannot anticipate changes in their design, nor do we have authority to do so if we feel something should change. Touching it as little as possible makes it easier to track upstream changes, etc. Based on that, I think the naming should be closer to libcurl.: - CurlUrl::URL_ENCODE should be CurlUrl::URLENCODE - CurlUrl::URL_DECODE should be CurlUrl::URLDECODE And so on, only differing if necessary because something is a reserved word. The API should be as exact as possible to what libcurl provides. The "helpers" getHost, getPassword, etc should be removed and should expose `curl_url_get` more directly. Of course, it should be object based instead of resource based, but that's it. A nicer API can be built on top of it, but I don't think that's the role this particular API should play. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for string backed enums
Hi Nicolas, thanks for the RFC, > There are also cases where using "->value" is just not possible. I mention > attributes in the RFC, which also mentions https://wiki.php.net/rfc/fetch_property_in_const_expressions (but with "For people that use non-strict mode, this extra “->value” is boilerplate that they'd better remove") > but we also have a case in Symfony where defining > service definitions in yaml doesn't work with enums because there is no way > to express the "->value" part. Symfony YAML has a `!php/const X` feature, which also works when X is an Enum::CASE; how about a `!php/enum_value` feature? Otherwise, I also like Rowan's suggestion of implementing "internal cast handlers", so that non-strict users could call e.g. `takes_int(IntEnum::CASE)` as well as `takes_string(StringEnum::CASE)`; but what about `takes_string(IntEnum::CASE)`, and `takes_Stringable(StringEnum::CASE)`? In any case, several people requested that it should require to be *opted-in* explicitly; but then [for solutions other than "allowing user-land to implement Stringable"] we probably also need a way to test whether a BackedEnum [instance] is "coercible"? 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] Auto-implement Stringable for string backed enums
On Wed, Jun 22, 2022, at 4:43 PM, Rowan Tommins wrote:
> On 22/06/2022 18:26, Larry Garfield wrote:
>> The argument presented is that it's easier to type `AppRoles::Admin` than
>> `"admin"`, because the former provides you with an error if you typo
>> something. That's a valid argument, but... not for using enums. It's an
>> argument for using constants.
>
>
> I wonder if the reality is that neither enums (as implemented) nor
> constants are the right solution to to this.
>
> What users want is some way to say "this value should be a string, but
> in this context it should be one of this list of strings"; or,
> sometimes, "is this string one of this list of strings?" Constants can't
> do that - they give you a way of referring to the possible values, but
> no tools for enforcing or testing against them. Backed enums can kinda
> sorta do that with a bit of effort, using ->value and ::tryFrom, but
> they're not really built for it.
>
>
> A better fit would be some kind of "domain type", which would allow you
> to write something vaguely like this:
>
> domain SymfonyPermission: string;
> domain AcmePermission: string { 'admin' | 'user' | 'bot' };
>
> assert( in_domain('admin', SymfonyPermission) );
> assert( in_domain('admin', AcmePermission) );
>
> assert( in_domain('random stranger', SymfonyPermission) );
> assert( ! in_domain('random stranger', AcmePermission) );
>
>
> Domains can also be considered sets, which you could compare directly,
> and maybe even calculate intersections, unions, etc:
>
> assert( is_subset(AcmePermission, SymfonyPermission) );
>
>
> The actual values would be ordinary strings, and type constraints would
> just be checking the value passed against the domain:
>
> function doSymfonyThing(SymfonyPermission $permission) {
> echo $permission; // no coercion needed, $permission is a string
> }
>
> function doAcmeThing(AcmePermission $permission) {
> doSymfonyThing($permission);
> }
>
> doAcmeThing('admin'); // no special syntax needed to "construct" or
> "look up" an instance
>
>
> Crucially, this solves the described problem of a library accepting an
> infinite (or perhaps just very wide) set of values, and a consuming app
> wanting to constrain that set within its own code.
>
> It's one disadvantage is the typo-proofing and look up availability that
> constants give, but you could always combine the two.
Interesting concept. I'm not sure if I like it yet, but it's interesting. :-)
It somehow feels related to Go's type aliasing, but I'm not sure if that's a
fair comparison.
Is there a type-theoretic basis we could look at for that? It seems like the
sort of thing some mathematician has likely thought through for funsies before.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for string backed enums
On Wed, Jun 22, 2022, at 2:31 PM, Alexandru Pătrănescu wrote: > On Wed, Jun 22, 2022 at 8:27 PM Larry Garfield > wrote: > >> >> So I am firmly against making it easier to (mis)use enums in a situation >> where constants are already the superior solution by every metric. The >> only argument I see is making case 1, transitioning from a string to an >> enum for a genuinely limited-case, easier. But in that case, the >> transition is going to have to happen eventually anyway, and that means the >> type is going to change at some point, and the same BC issue will appear, >> just at a different time. Unless the intent is to then never change the >> type and keep the function incorrectly typed (from the POV that it's >> logically an enum, even though string typed was the best/correct type for >> years) forever, in which case... use a set of constants. >> >> > > Hi! > I'm with you on what you mentioned here. > > But also, I think the need I understood arises from another case that is > neither 1 or 2. > When you have two domains the value might need to be represented as a > backed enum in one side and as a string in the other. > As far as I understood, this is the case, with applications that are in one > domain wants to have a proper enum for let's say the app roles as the > possible roles are just a limited set. > That application is using another library to configure the ACL using those > roles and this is another domain that does not have a limited value on the > role representation, it's just a string. > Naturally, you should just transform the enum instance to the string and > that should be done using the value property. But this does not work for > configurations done through attribute parameters. > And I think this is the only problem we should fix and that's fixable by > https://wiki.php.net/rfc/fetch_property_in_const_expressions Yes, I'm planing to vote +1 on that RFC. Although in that case, the same logic for why to use a constant instead still applies. > What you mentioned about developers using enum in the wrong way is > completely true and it's been a long effort for me in explaining this. > I was hoping it would be diminished somehow by increased popularity of > enums, now that they are supported by everyone. But the usages are also > increasing. > > Regards, > Alex I may need to publish a blog post on this issue specifically that Symfony and others can point to when people keep asking them to do the wrong thing. I fully understand that major frameworks and libraries (Symfony et al) are getting the pushback of people trying to do the wrong thing, but the solution should be better educational efforts so people stop trying to do the wrong thing, not making it easier to do the wrong thing. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] PHP 8.2.0alpha2 is available for testing
PHP 8.2.0alpha2 has just been released and can be downloaded from: https://downloads.php.net/~pierrick or https://qa.php.net/ or use the git tag: php-8.2.0alpha2 Windows binaries are available at: https://windows.php.net/qa/#php-8.2 Please test it carefully, and report any bugs to https://github.com/php/php-src/issues 8.2.0alpha3 should be expected in 2 weeks, i.e. on July 7th 2022. Hash values and PGP signatures can be found below or at https://gist.github.com/adoy/33f3c8fff8ccaa80d57079cb849cc9c3 Thank you, and happy testing! Regards, Sergey Panteleev, Pierrick Charron & Ben Ramsey php-8.2.0alpha2.tar.bz2 SHA256 hash: b611eeff65d0b3e9182de230163e2345ecfd6fabb4e1e009dce099ba63a3f221 PGP signature: -BEGIN PGP SIGNATURE- iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmKx43URHHBpZXJyaWNr QHBocC5uZXQACgkQKGrx+Yl0adx9RA//RArQCXUgZYDz0eRCK6E1cfVFRtwU6dLh OU/j5lNbpAuMzDTcPzNd3akziu5dTrHenVE3QWHFNQruuqvmPwRSRxCwB/QymbXv f4aembKwwcn/g9Aos+bSk1mPncIMv21eFOBWCwFFB3/hMJBl3eltAOzw2w5K17WV XJwc7NwcwBwg7UW6qdsj4WXbIqzw+4Uef3jAciKuUOi/5v+z1YKqtVXF017qq9nr LUwV+NMA9coGq1zhjUQ6r4NtLb4YMUB/2nGoEKpbGUmcm964yl9v4hI4MciYSqw5 DGSDmJb8oZK6Yy6vIFG7raa3nEWDFyVCv6zaqUMod9NJn9tGy6NDqooVSATvSeYP nid4fN7OveypdX7iW/qr6AQbgbLG7jhvJoKmPHLRPFkSKZ7EgMoPoOgD1U42DdzW rNYzO3GPxV6FHvXFcT8gKqXV7SsufsapsmgICY8bRkGIOSWGzgpf66ijRZ2aKkbx /ynTkYg+LcY6ntMPxslZ2HeDS8lwmJciRWVGEfeSeORqJYO8sDmwp2jk+Ffgl+Xj LE6wnYn3hjbQLKZ76e1qZPMFfibs1Ygj8Lp5vHxSA3tY3LYg2j8q5ObGBhd4Y77g lotu0pNWpdmkkQGXudX0dmt0emR4NB0eEe0vUhGDHyoKqbkpx6ZKvEyxgV2p7Lpz NoE8pgkw2LU= =XOZ9 -END PGP SIGNATURE- php-8.2.0alpha2.tar.gz SHA256 hash: 92d8747a4380ae3e8020a1671a51173a051bbb3eb02af80962785dea342e5801 PGP signature: -BEGIN PGP SIGNATURE- iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmKx43YRHHBpZXJyaWNr QHBocC5uZXQACgkQKGrx+Yl0adxsQQ/9E2JDKA5PcQVqswswItJuuQFLGjZl6sr6 HkeAdnyyzKlUlWZ9qmfWrs/1y/gaSw2MD6NVOZ7Fuu8awtd4kw26D36IQSoMzK2j QBXn/c5Jn7q6QmZKlJINxr2eEAuOnoPrGBssjrVvA19cyJ3nS4fRQkTpWJU9abOc IVgtI01Gmb9RmY+tTy8zFeBbrTzb149nFIuB4k3oN3jpy9aYV7AToF1TeH+MQ8ei oRZ5LNmhVqNxIh+hxh/7htGX9DonJx2p2KyOXv+qd07yRbw67rc660XmA+uoxl0d 55kCTiba3u9JseoOzXQp7En3Y1Wu8NlbGgUAkUujC0qulqK5zSVJ8erm/9+r5LOC KcpKFb6iaqTckyOBPRakfmDg6prOun1NG8Xvl5MS2YA/M22AOeVnvsfhQ8MyVZMO qVhPPAw60ZF7bA2rnYUWnfntqFfySGZbfNHMp6XN7zb0esB9eCqVABfzcE4g3/+O gbbrTqIkx2WoF79gmPkAgJRyQYbX0z4bBjlLazSKCRf2Vlftga5opWB2BGI0giKr hnwuiSlrKDIAWxvMlPZCI+wYsrnkoa+n8inEya/KMtqzNweRqvJwyDYnRVIjhgPf JBtaeclmPSJTnSN5TXEPZ6TPiynx+UtNHfteKARz6wIRECMxL06OQxEOAyCkmUQZ ADBvDWLq00w= =SSiL -END PGP SIGNATURE- php-8.2.0alpha2.tar.xz SHA256 hash: c7a44ae890c8e6dbb69ab8a6bc6385ddaae34a35af4d9acf87ffa00f5158c2d8 PGP signature: -BEGIN PGP SIGNATURE- iQJFBAABCgAvFiEEEZjAEXWTSXpexcGZKGrx+Yl0adwFAmKx43YRHHBpZXJyaWNr QHBocC5uZXQACgkQKGrx+Yl0ady+chAAmh6gavwz/5vXu2nLxmU7p1+kPNaPpHgT j5Vo5WGSPk9FmEhHa2mQPaK47AblGHqm3fN4tFOgDFIgnWxBujE9NznyM1K0jV2T tRsw9A7kzRjKTskPTW+y4KYXXy9S2o0wjRoQhZIr5LxmKK6PcZXnS25aSUCkQP5Z VUpqSDp7uWqmRNQzarwoJ4cix0nQMhuzCRPCXf8N7bvnqOhu/0loRj1wgV4MOX+d acuyBqD4tle1J49FGgV9uRtwYsGN/TxaeHc0xU79RLjX11b/GrlDcWzlbDAIMbZ5 g3EKrtlflN9kbWEPbt6VADtATPpWsILTOGp+9XsWoLSCs4/veNaGKkmxA4JxYPC0 pNyYeffkyj0x3OquIQ1H3SyVi06AaAv7E+eulTZdEII3xEzG0JtDHO4LiGwuX7cK wDJw+wK24Uncsay1gbHiSaHvHaNHLw35pwfGsTfHLt9/Rw6zc6Qvn5rux4viDU+s eieU/DN8A4qKTehL0/IwH+wJPZ5mWdUICNJGik2MRqPO6XveCSo1nXQIcM2hYq3P uc5bPSvyylTyACpeZCiWx9FEV1+tgvL45MfLJrB0H3395zw4wqqS33fhTKhVJQ4f BkdH1YQJeU/cTfchDPi+siiuEOHm2ANJejVHC9rL5COMk8wpIR3IzZr+XLue+nnG mjgpDwFz9T8= =y4P6 -END PGP SIGNATURE-
[PHP-DEV] PHP 8.1.8RC1 Available for testing
PHP 8.1.8RC1 has just been released and can be downloaded from: https://downloads.php.net/~ramsey/ or https://qa.php.net Or use the git tag: php-8.1.8RC1 Windows binaries are available at https://windows.php.net/qa#php-8.1 Please test it carefully, and report any bugs to http://github.com/php/php-src/issues Hash values and PGP signatures can be found below or at: https://gist.github.com/ramsey/024736f8887b50ab47a4982e6ae9be31 8.1.8 should be expected in 2 weeks, i.e. on July 7th 2022. Thank you, and happy testing! Regards, Ben Ramsey, Patrick Allaert, & Joe Watkins php-8.1.8RC1.tar.bz2 SHA256 hash: b123ac066844fc1bd1e4271eb6aa1bf81df1ea433b118144aa538613a052b98c PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmKx7eAACgkQ+cOdwLlp hUTRxg//V5epZIMyKQz6chRyKcfrkw2taZr0lrqwFqeOSx5xZ5iWm/UsTb0j7c3i A/3LP8QMpuuAt4YDxIy6NxyvFpPyRmXHwr62pYlX85DigbyaLrLlS63SXw2wzRC8 7hde+z0+qc/SIDqS2gWDkVGbpsWG8vsPK6wRp0tTUF63VTdp6vbnh66zSJ/UDN6k R4Lne9oBkwRb5NdZhOnN0Wfr2nFdMl7tqvJrwpKSq2CWtUmCAc4LvD8qhojArr5T sks5Y8ISvZrYudElW1Av8hFa/lCJ85I9g7lPl18ilOGQTdBKHh8CGg3V7E8Ri7tT Wq2n9g+aDm+jVw9mORcsn9iQ2jYXTpyiPX0McUHvsmESap4ny4Gtq9wBTHd1M3Ej rCYY11OEpi+5XiiYsn2f0/ueZkh0Vf2QO2lWPivc/XbNSi6QN7MH+IcVnkt4WpTd r8Q79hyRp1m1NKgeL6Cj24njNVHBE9uKzDOdpQDpb1orJ+9XC/O38zUEf5vwnQdu s76E7//yUMD4k/LgWlxMi0uYjlGlk73XRKGU+BbJ52z82ARCC7DaAWzuLv42UZ0V /tNG3mX6z5tCbSx97BRmXAKqFGu2SWw7u/59RKFhFlGLhpZHwEtsWudN/WdTg7xl 7vkQWi5n4evxbDEiumOBC/1fJaUnAT0qe0Ea34wnHdZCVIGr0lk= =ZFfY -END PGP SIGNATURE- php-8.1.8RC1.tar.gz SHA256 hash: 3a2a22fadee88bfc3ffd389af8875607d3cf3d22b62d02cc0747edec36aadfa0 PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmKx7eAACgkQ+cOdwLlp hUTZjBAAi3JEqeGqSReTTf9Z2lReDEa5RzvyKNoJfqaSbcpiHNKo0w1Mz1ShURjD e/qHvFCrBXIYMFNBPmT+gudQsA3iztQSLZfPGvGqmZvcC6vJpsq1Wn7nhyo7kvAp lR6CaPdggrmWwQfGEtjFe/J2CFeSgDkXFfQf5iT1G1i8a/uOIHZ/uJXsXq9E11WR 6t/coQ/3s7WIY7Z9vYEaOsbQlAOWlHi/99V/cbWn75NshqIVG3Kws15ABzKtCm9p znbKvXYNyPO1XaMPOBAP5OI2kUQ7Q6LS++s53TO6jjdDrYXTNtTZdFTgDyamXD2J 92VP+UPhQd4XSg/h+M497BXUF9BXzVnukamHKUEQRzMIaBaIzvK6REEIRcEKfp8p Cm5mK5x2F+RgsCIZK0BT6s6fgJTmJNK+ADkTtQ/QhdSUSbyqNu6ijfDkeYoE6I8E bNHzLOlrj6iXTvrQh1hWG1KQ05cbeK+VA8h8Us0Ag6H6MoQaYZ7DrvvnJqRO4rPU agujimNYl07WmmWYikdyPI78H3iMzIooV/7Xo6U3qococh/vQRzNGFLITL5WMQRj uRWUVDLDVP3uPyMo6PHra1MM4jw73wkkLefO9/vIbSH0FtAgridwv4lzKKocDvW9 VC/0MiRNYv9/zZc2Fu1vRjYH9hEp5vhen0q551kqAnargDSGRI8= =JuKZ -END PGP SIGNATURE- php-8.1.8RC1.tar.xz SHA256 hash: 5b69c2f4c2c0c9cd4220c82b15f9b870e595350dabf2b46d0c218bc694af491e PGP signature: -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEEObZBND2MEEsrFG3D+cOdwLlphUQFAmKx7eAACgkQ+cOdwLlp hUSsng//VskqBoagaX8BeOuE6JYoK+hJrI922k866lA1Qe2cawiEd7jTGWs4cl6Y /pnckLa1dJ7s3Dpv9KuZARbdQPWz+QJkp8tMaFNHVdIWzazoJ0tAVc7DD0/1eZ/e TDNcc91oDS34ADcnlFPNEUP4W1JET9EdE753THK8DNAAezWdhBxTwY/B75CPV2N9 2DdzfYO3io0TcJD9o2TAUYeFRGGvMAR7D8fFFuFAgEzyDXqA0OGRvPmdX3W8pL0U cRKKIIH749osHM8Dq9nmtDaulQpTaVzXOSYQ9a4mgot5QY3W5ch1ucwne9cVTwhl 919Sl9fKRNpJ+fxVIIwUUrzoZBnrheZce6zlceq9DtL333thi79DG9s8i/l4eHmL LJbl6MzACC78myTlC7nCx08IWNPVm6Ov8/OoVWm7P2I9id5xZbHGXkp7iZnEyO2a xfksYd915gblbxwg8mZv3mO4SsDgXgAsDxuPSCDEq2D/9CmxnYjrU1xYIzYiaYDg LjAhtSfPUlTeyQrH+5FGqOkX+QZDshlCQK5PyhX4phqWh7QCH1qKPZbpUDuFT4sg /X4fgRiw4gC6s7XNag69zLyWhElH0FFY1F6afNzBIrrtIISPxgyM15PXndI2YdM1 fu/3lLJqf4DwES2jyuVLQXqEkGpf+XIqv8TzkajYGGkPO74Aqg4= =9mzr -END PGP SIGNATURE- OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC][Under discussion] Fetch properties in const expressions
Hi everyone As foreshadowed in the last e-mail I updated the RFC to restrict the fetching of properties to enums, and the PR to match it. Unless there is more feedback I'd like to start the vote early next week. https://wiki.php.net/rfc/fetch_property_in_const_expressions --- Hi Claude > I feel that, in any case, allowing unrestricted fetching properties in const > expression in is semantically incorrect, because properties are fundamentally > mutable. I am not speaking of creative use of code in order to achieve the > effect, but of the regular semantics of properties. > > For me, it seems reasonable to restrict the feature to readonly properties > (including those of enums), because those are effectively immutable by design. I thought about this option before the last e-mail. Unfortunately since readonly properties can be initialized after object construction the same problem arises. You can find an example here: https://wiki.php.net/rfc/fetch_property_in_const_expressions#allow_all_readonly_properties --- Hi Alexandru > I really think we should have the same limitations for "->" and "?->" just > like we have for "new", with the same reason that that was disallowed. > That would mean not allowing it in the default values of a property. > Maybe I'm missing something but it looks like this was the plan all along as > you don't have any example that would include that, neither in the RFC or in > the PR tests. It was always planned to allow -> in all constant expressions. I added tests now for all the constant expression positions. Now that only enums are allowed I don't see a big reason for restricting the scope any further. > An option to limit it to enums in the other 3 places, static or instance > property initializers and class constant initializers while allowing it on > all objects in the 4 cases where new is allowed. > > Or yeah, limit to enum in all 7 cases, if that is a lot simpler. > I wouldn't prefer it as I still have cases in mind where I'm not dealing with > enums but it's your call. I mentioned in the last e-mail that there was an additional problem regarding caching of constant expression results. I added a section to the RFC (https://wiki.php.net/rfc/fetch_property_in_const_expressions#caching_of_constant_expression_values) in an attempt to better explain this. I would rather delay support for other objects until we're confident we have a good solution and haven't missed any edge cases. Regards, Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] PHP 8.0.21RC1 Available for testing
PHP 8.0.21RC1 has just been released and can be downloaded from: https://downloads.php.net/~carusogabriel/ Or use the git tag: php-8.0.21RC1 Windows binaries are available at https://windows.php.net/qa#php-8.0 Please test it carefully, and report any bugs to https://github.com/php/php-src/issues. Hash values and PGP signatures can be found below or at: https://gist.github.com/carusogabriel/9300c734f38180557bcfeccb887b9597 8.0.21 should be expected in 2 weeks, i.e. on Jul 9 2022. Thank you, and happy testing! Regards, Gabriel Caruso & Sara Golemon php-8.0.21RC1.tar.gz SHA256 hash: 414fdbb6482cd5258b408f2e1cfc51190d9715603be8acf6423428a587e9c5fe PGP signature: -BEGIN PGP SIGNATURE- iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmKxj9UWHGNhcnVzb2dh YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj8neD/4lv2Y01JD0vWYlBq/opPx12rq9 zeXiws/K7H8AXXWp9p8MkbXFIbC+O0sLQwzUW5zJAZO0ZRN+Jde3ZPn3tL+oakv2 AwUuengyRYaMlJfFvWk7Ow1gb1jtYqhNUjKAVZ2u7nDfV/ieuR+w8N+RO7RyGkTd KzR/PYtT9jHPkDwoTgKRbsGS4INyYn2RmH9WtSX3Zt0yMX4eAdq56/0y6/3ZqR/O HEAwtZUIv4bYzAK8f7viZJ4Bcb4H034dUXZ3Kc6pt/+cud6moc74UiF0eV5BaG2M MxxHMZcWqx1U8WUEW8GztvrO97QmJbKBxrjPhYX682j303ZQaQ2pynpeWxkjwquj Vom281kHxV07iqyBpGUNMZjMYexVIpZ7GuPp585GptedHfsPP+8n7Uorx1I0e8eH iLFoSUGf1oM5Rwgis7zd/PNIWfELpMyNEWckZ4SP3jfgLzPp1MbUnZgRvc0TKK1J R+4D7exd5VEqsGHEKBIpOsTNyqbb716ExUUvhqqN85aAkdTSZzhN73TqEZy0Oz3x cytyZv8qZWMFcJUmEIyGJuNBbyiy75/yNxX9LXiKMYJHddVm3ZimCTYKK2SJQvfx xwqJ2aQyWRx1gtwWAFLHT+mOqq63Hl3G3gxk4A4l8/jgzCjy6H2a6m5P6kWBYQ7E adULGrpIQAbXGSu+Vw== =6EZJ -END PGP SIGNATURE- php-8.0.21RC1.tar.bz2 SHA256 hash: 92e1021d81b38c258a6f59f0b8cb431f6bd908e1cfa5cad50958b9998411229f PGP signature: -BEGIN PGP SIGNATURE- iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmKxj9UWHGNhcnVzb2dh YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj4pkEADPE/Yl9YNH9FrA+qFZlXyGa9So TeTYUCOPLMroOwz9f6xbjU6KRffSJSprtlwdtTErxafMuSfyDGQI4wyBtajc7Ude T8ZwjrsZ0mCW8C05Ma1NLBhhvCC9ZKBHcH6VkEkbD6JhdjGIbcI1OiOHfzWdPaMA cIgyV0Ojpojz90s+h4w9odJt6eAblD+89tbqdkL6X12MX1rBXoHgk09UGisEG1Sg 66/Iv39y2EP736Il2jn1HHEPclf9iOHIm7tSKev6chvV2Hk/dIoORuxC7Xr1Lfd9 sKoYzP7ky8I5FCiCdqZcRL9r+C1MpyISkpDeyBdBNyRgStNh9pVfPdNrsEVonuZJ HAzagWPH7dPy2w5d05m6C3WLTyKC5LVEwMMbkJgnWu6IWS6IP1TqpHgMkxA9NzSv VDA4ZtPAYDoDN9r5sRJna6jXVP/ehwm+VnFMEnIZ1VrWZDQG4t0tsHBwZzWOJhm3 Lu70xVKQBrAZlsUrHIyzsoaahc0vO6aOudj0Wl7FKqD8ulYKoeecR2e9UfUTGHyR yyFSJY6tjjivDDkHn7wkL8uJ4GTLER7K5kYSOJFFmLVOwaokAeyDZq0x0vuTcLGG HP90i0/0jpFC85jkBJZ1CGoyQjdVExgfGdhSIvkaianNCEaAclfuQ9F0zqQovGyp Eqn6eSdMn559emjWig== =pbcB -END PGP SIGNATURE- php-8.0.21RC1.tar.xz SHA256 hash: 9c617165625e17344481333a820a3391cbd3f1b8925ed1c274267701fbb17f7c PGP signature: -BEGIN PGP SIGNATURE- iQJJBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmKxj9YWHGNhcnVzb2dh YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj47gD/METH6ZC75LSkYEWuZ9RH/UIZEV 3ioskFcBLJMxSchme4IFi0gaadwZB9UuWKCWM5OhWAtItORwX/jERmlRCDmjSZov u9fLRrwhvP1l0ZNI7yEp2/UsTjTkxWJgAHYG6d2oJDcAkMY//N5EXKjFrhclyWyG V8e5in/7JXczFIp+cnqFc+yNTSRbUqIzvjdqu42lBvHTYfpS7H+90VIyh/hA4EhM 0J2R3jHU9WiokIMX+UlfKWMiCX0iSd2RjQYu1NmItBY0JRRXtqTWUWRoZbG0kSEU wnhDTJ//CqfGbCMDyr04VBOTfjJk65PVpJ1zmEcQFykIvug1ffw8S0vDZpf2Jrkn zh7arX926gxYH8n1g7DNJWtgRIyiRbcEdb04Sbvn/hXyfe71a3VABNnLJmSFQ5Dc XgxXwt8zHMGvUHK8dVNtUM4pEFrRqFjPNoF/UGyjgMEC6ABQr3X0BP9koRBXO2Ef OZsNuSEIsOmENKxB/g0gcGxP0FWDnYMK/ovzOQ8H/WxJn1vqBMFz9aBXj3RQSWTM HK/I88ObR9JlCnsF97PKMFcF1pS55+67jADm9evaB9l6tLA/5lonkxvyTfUU8Y4i C9g/L+QyLGtty8/TsUbJ0JJh/bHiIoEBHcLr84rEuh1IEJxoNwsdhbOGMxAcoLZv qdbzCEpOM1fC1/5Q =G3SK -END PGP SIGNATURE-
Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension Improvement
2022年6月23日(木) 0:02 Tim Düsterhus : > Hi > > On 6/22/22 16:35, Go Kudo wrote: > > No additional comments seemed to be forthcoming, so the RFC was upgraded > to > > 1.5. > > The following changes have been made > > > > https://wiki.php.net/rfc/random_extension_improvement > > > > 1. Add: `Refine classnames` > > 2. Add: `Random\SerializableEngine is outdated` > > 3. Add `Add Randomizer::pickArrayKeys(array $array, int $num): array > > method` *1 > > 4. Add `Random\SerializableEngine is outdated` > > 5. Remove: `PCG64 is ambiguous` (replaced by 1) > > 6. Remove: `Mersenne Twister is ambiguous` (replaced by 1) > > 7. Remove: `Randomizer lacks array_rand() replacement method` (replaced > by > > 3) > > > > *1: Added with a little sample code. > > Thank you for the update. The grouping makes sense to me and it looks > very organized. > > Let me just propose some wording changes: > > a) > > > Random\SerializableEngine is outdated > > I would rename the headline to "Random\SerializableEngine is not > useful", that's a little more fitting. > > b) > > > CombinedLCG is outdated > > I would rename the headline to "Random\Engine\CombinedLCG is low > quality", that's a little more accurate. > > c) > > In the "Refine classnames" section: > > > To make it more readable and regular, the class name is changed as > follows: > > I would reword this as: > > To clearly identify the implemented algorithm the PCG64 and > MersenneTwister twister engines should be renamed to their canonical > upstream name: > > The issue with the previous wording is it's not clear what "more > regular" means. > > d) > > For the vote titles I propose the following changes for a more > consistent wording that succinctly describes the change to avoid voter > confusion: > > Engine implementations to final >to > Make all implemented engines 'final'? > > Remove Random\SerializableEngine >to > Remove the SerializableEngine interface? > > Drop Random\Engine\CombinedLCG >to > Remove the CombinedLCG engine? > > Add Random\Randomizer::pickArrayKeys(array $array, int $num): array >to > Add the pickArrayKeys() method to the Randomizer? > > Rename Random\Randomizer::shuffleString() to > Random\Randomizer::shuffleBytes() >to > Rename Randomizer::shuffleString() to Randomizer::shuffleBytes()? > > Change classnames >to > Rename PCG64 and MersenneTwister? > > Implement Random\Engine\Xoshiro256StarStar >to > Add the Xoshiro256StarStar engine? > > Best regards > Tim Düsterhus > Hi Tim Thanks for the suggestion! It looked much better to me and I have reflected it in the RFC. "Remove the CombinedLCG engine?" replaced by "Remove the CombinedLCG class?". The reason is that the implementation will still remain for backward compatibility. (only the class will be removed). Regards Go Kudo
Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for string backed enums
On Wed, Jun 22, 2022 at 6:01 PM Nicolas Grekas wrote: > Hi Benjamin and Derick, > > I'm replying to both of you because I see some things in common in your > comments. > > > >> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums > > > I would prefer if this was an explicit opt-in to have a __toString on a >> backed enum. Maybe a special trait for enums that has the implementation, >> so that a custom __toString cannot be implemented or a new syntax "enum Foo >> : Stringable". >> > > We can make this opt-in by simply allowing user-land to implement > Stringable. > This is a different solution to the problem the RFC tries to solve and I > would also personally be fine with. > I would then *not* try to limit which implementation of it is allowed by > the engine. Instead, I would give all powers to user-land to decide on > their own what makes sense for their use case. As a general principle, I > believe that empowering user-land is always a win vs trying to "save them > from themselves", as if we knew better than them what they want to achieve, > and especially how. > > >> My concern is that auto implementing __toString, will lead to decreasing >> type safety of enums in weak typing mode, since they get auto-casted to >> string when passed to a function accepting strings. This effectively adds >> more type juggling cases. >> > > I don't share this concern: if an API accepts a string and the engine can > provide a string, let it do so. There is nothing inherently dangerous in > doing so. But we don't need to agree on that if the proposal above makes > sense to everybody :) > > >> The example in the RFC about attributes accepting strings or Enums can be >> solved by union types on the side of the library developers, it doesn't >> need to be magically implemented by the engine. >> > > I extensively explain in the RFC why this should not be on the side of lib > authors, but on the side of end-users. Please double check and let me know > your thoughts. > I don't fully agree with your argument in the RFC. You mention as an exmaple that users want to pass PossibleRoles enum values into the IsGranted attribute. But the way Symfony works as you know, you can pass arbitrary role names here from the library POV, and applications can add their own. So naturally the API is to pass a string. So "PossibleRoles" can only be a user provided enum, it can never be a Symfony type. I don't see how PHP should provide a workaround for Symfony and its users wanting to allow users to use an arbitrary enum as input to a function. In this example, in Symfony code you only expect "any" BackedEnum and cannot validate that it is a value of PossibleRoles enum. As such Rowan suggestion to use constants is the way Symfony should recommend their users. > >> I don't consider "use strict mode" a good argument to avoid this problem, >> because that has other downsides such as overcasting. >> > > I'm 100% aligned with that. > > 2. It is not implemented for all enum types, only for string backed ones. >> This change would now make different classes of enums, without them being >> differently inherited classes. >> > > This would also be solved by allowing user-land to implement Stringable on > *all* kind of enums. Would that make sense to you? > > >> 3. The main use case seems to be to prevent having to type ->value, which >> would otherwise indicate reliably whether an enum is used as string >> argument. >> > > Yep, that's a "strict mode" approach and this RFC mostly applies to > non-strict mode. > There are also cases where using "->value" is just not possible. I mention > attributes in the RFC, but we also have a case in Symfony where defining > service definitions in yaml doesn't work with enums because there is no way > to express the "->value" part. > > If that's the consensus, I'm fine updating the RFC to turn the vote into > whether "allowing user-land to implement Stringable on any kind of enums" > is desired or not. > > Nicolas >
