Re: [PHP-DEV] [Vote] Pipe operator v2
Hey Larry, there's still ongoing discussion on the semantics, and mirroring implementation defined semantics from the implementation into the RFC is not the way to go. The RFC should discuss reasons of why semantics were chosen and the implementation then be decided upon it. Describing it as "design artifact" is not okay. I'm voting no at this point, to force it to be postponed to PHP 8.2 with proper thought of what the semantics shall be. Possibly the semantics are fine (I tend to disagree with the current ones, but that's rather point for discussion), but they are not discussed enough, especially as they only got described in the RFC in the last minutes before the vote. Bob > Am 06.07.2021 um 19:13 schrieb Larry Garfield : > > I have opened the vote on the Pipe operator RFC: > > https://wiki.php.net/rfc/pipe-operator-v2 > > The vote will close on 20 July. > > -- > Larry Garfield > la...@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Pipe Operator, take 2
Just to clarify, I said it didn't look like it could be a pure AST implementation, and that it looks like you may need one additional instruction. It does look that way to me - if only to throw a sensible error specifically for pipes but also because it makes the imposition of specific behaviour for pipes a little easier, but it doesn't make it a super complicated thing. I also said I didn't know what the right answer was with regard to refs. I still don't, although I lean towards blocking them at the moment having spent a little more time looking at it. I don't really think we've had long enough to have this conversation properly. Cheers Joe On Tue, 6 Jul 2021 at 19:05, Larry Garfield wrote: > On Mon, Jul 5, 2021, at 11:05 AM, Larry Garfield wrote: > > On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote: > > > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote: > > > > Hi folks. Me again. > > > > > > > > A year ago, I posted an RFC for a pipe operator, |>, aka function > > > > concatenation. At the time, the main thrust of the feedback was > "cool, > > > > like, but we need partial function application first so that the > syntax > > > > for callables isn't so crappy." > > > > > > > > The PFA RFC is winding down now and is looking quite good, so it's > time > > > > to revisit pipes. > > > > > > > > https://wiki.php.net/rfc/pipe-operator-v2 > > > > > > > > Nothing radical has changed in the proposal since last year. I have > > > > updated it against the latest master. I also updated the RFC to use > > > > more examples that assume PFA, as the result is legit much nicer. i > > > > also tested it locally with a combined partials-and-pipes branch to > > > > make sure they play nicely together, and they do. (Yay!) Assuming > PFA > > > > passes I will include those tests in the pipes branch before this > one > > > > goes to a vote. > > > > > > Hi again. > > > > > > With PFA being declined, I've again reworked the Pipes RFC. > > > > > > 1) It now does not use PFA in any examples, but it does use Nikita's > > > first-class-callables RFC that looks like it's going to pass easily. > > > > > > 2) With major hand-holding from Levi Morrison and Joe Watkins, the > > > implementation has shifted a bit. It now evaluates left-to-right, > > > always, whereas the previous version evaluated right-to-left. That > is, > > > instead of $a |> $b |> $c desugaring into $c($b($a)), it now becomes > > > effectively $tmp = $a; $tmp = $b($tmp); $tmp = $c($tmp); That matters > > > if $b or $c are function calls that return a callable, as they are > then > > > only called when the pipeline gets to that part of the expression. > (If > > > all the functions involved are pure functions, then it doesn't make a > > > difference in practice.) > > > > > > 3) I included references to several existing PHP libraries that > > > implement similar logic, in mostly complex and ugly ways. > > > > > > 4) Of note, Brent posted a Twitter poll last week about pipes, and the > > > response was overwhelmingly in favor. > > > (https://twitter.com/brendt_gd/status/1408271132650885123) Naturally > a > > > Twitter poll is extremely unscientific, but I think between the > > > existing libraries and the response there the answer to the question > > > "is there actually a demand for this feature?" is unquestionably yes. > > > > > > 5) Examples have been reworked to be a bit prettier. > > > > > > 6) Added another language reference that has a pipe operator that > works > > > basically like described here. (OCaml) > > > > > > I am planning to take this version of the RFC to a vote on Monday or > > > Tuesday, as Tuesday is the last day possible to start a vote for 8.1 > > > features. > > > > > > --Larry Garfield > > > > Based on feedback on the PR, I've updated the RFC to forbid functions > > that pass or return by reference. They're not really useful in pipes > > at all, and were only supported before because the implementation > > happened to allow it. > > > > The PR hasn't been updated for that yet, but I figure that's easy > > enough to update post-vote if it passes. > > Sorry for the noise, but after some discussion with Joe it looks like > blocking references in pipes is actually much harder than it sounded like, > and would require a completely opcode based implementation rather than the > completely AST-based implementation. References on pipes are not really > useful but in practice they don't hurt anything. I've instead added more > tests to validate that they behave "as expected" and noted that in the RFC > instead. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
[PHP-DEV] [Vote] Pipe operator v2
I have opened the vote on the Pipe operator RFC: https://wiki.php.net/rfc/pipe-operator-v2 The vote will close on 20 July. -- Larry Garfield la...@garfieldtech.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Pipe Operator, take 2
On Mon, Jul 5, 2021, at 11:05 AM, Larry Garfield wrote: > On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote: > > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote: > > > Hi folks. Me again. > > > > > > A year ago, I posted an RFC for a pipe operator, |>, aka function > > > concatenation. At the time, the main thrust of the feedback was "cool, > > > like, but we need partial function application first so that the syntax > > > for callables isn't so crappy." > > > > > > The PFA RFC is winding down now and is looking quite good, so it's time > > > to revisit pipes. > > > > > > https://wiki.php.net/rfc/pipe-operator-v2 > > > > > > Nothing radical has changed in the proposal since last year. I have > > > updated it against the latest master. I also updated the RFC to use > > > more examples that assume PFA, as the result is legit much nicer. i > > > also tested it locally with a combined partials-and-pipes branch to > > > make sure they play nicely together, and they do. (Yay!) Assuming PFA > > > passes I will include those tests in the pipes branch before this one > > > goes to a vote. > > > > Hi again. > > > > With PFA being declined, I've again reworked the Pipes RFC. > > > > 1) It now does not use PFA in any examples, but it does use Nikita's > > first-class-callables RFC that looks like it's going to pass easily. > > > > 2) With major hand-holding from Levi Morrison and Joe Watkins, the > > implementation has shifted a bit. It now evaluates left-to-right, > > always, whereas the previous version evaluated right-to-left. That is, > > instead of $a |> $b |> $c desugaring into $c($b($a)), it now becomes > > effectively $tmp = $a; $tmp = $b($tmp); $tmp = $c($tmp); That matters > > if $b or $c are function calls that return a callable, as they are then > > only called when the pipeline gets to that part of the expression. (If > > all the functions involved are pure functions, then it doesn't make a > > difference in practice.) > > > > 3) I included references to several existing PHP libraries that > > implement similar logic, in mostly complex and ugly ways. > > > > 4) Of note, Brent posted a Twitter poll last week about pipes, and the > > response was overwhelmingly in favor. > > (https://twitter.com/brendt_gd/status/1408271132650885123) Naturally a > > Twitter poll is extremely unscientific, but I think between the > > existing libraries and the response there the answer to the question > > "is there actually a demand for this feature?" is unquestionably yes. > > > > 5) Examples have been reworked to be a bit prettier. > > > > 6) Added another language reference that has a pipe operator that works > > basically like described here. (OCaml) > > > > I am planning to take this version of the RFC to a vote on Monday or > > Tuesday, as Tuesday is the last day possible to start a vote for 8.1 > > features. > > > > --Larry Garfield > > Based on feedback on the PR, I've updated the RFC to forbid functions > that pass or return by reference. They're not really useful in pipes > at all, and were only supported before because the implementation > happened to allow it. > > The PR hasn't been updated for that yet, but I figure that's easy > enough to update post-vote if it passes. Sorry for the noise, but after some discussion with Joe it looks like blocking references in pipes is actually much harder than it sounded like, and would require a completely opcode based implementation rather than the completely AST-based implementation. References on pipes are not really useful but in practice they don't hurt anything. I've instead added more tests to validate that they behave "as expected" and noted that in the RFC instead. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] Add PDO function: mysqlGetWarningCount
My previous email had an ambiguous subject line. My apologies. I've moved my RFC to the voting phase. The proposal: > Add a function that exposes the warning count of the most recent statement for MySQL: $pdo->mysqlGetWarningCount(). It returns an int straight from the MySQL driver. This fixes the open bug at: https://bugs.php.net/bug.php?id=51499. Voting will be open till 2020-07-21 https://wiki.php.net/rfc/pdo-mysql-get-warning-count The pull request (with tests) is here: https://github.com/php/php-src/pull/6677 Thanks for your time! Daniel
Re: [PHP-DEV] [RFC] Under Discussion: Default User-Agent for cURL
Dear internals, I didn't receive any more feedback on this RFC, therefore I would like to start voting next week on the RFC as is. Rationale: - I would like to stick with a distinct curl.user_agent ini option to avoid the BC break. - Also using PHP_INI_ALL as the options visibility is matching the core user_agent options behaviour. That is being able to modify the user_agent via ini_set during runtime. Thank you for all the contributions! Am Di., 29. Juni 2021 um 10:35 Uhr schrieb Michael Maroszek < par...@gmail.com>: > Hi! > > Would anyone else be in favor of reusing the user_agent setting for cURL > despite the BC break? > > At the moment all possibilities (user_agent, curl.user_agent > (PHP_INI_ALL), curl.user_agent (PHP_INI_SYSTEM)) seem to > have negative votes attached. > > I am unsure if it makes sense to go forward with the RFC and if I should > bring the RFC to a YES/NO vote for the feature itself and the three > mentioned possibilities to choose from as a secondary vote option. > > I'd love to get some help on how to proceed even if the answer might be: > don't proceed. > > > Am So., 27. Juni 2021 um 09:25 Uhr schrieb Aleksander Machniak < > a...@alec.pl>: > >> On 27.06.2021 08:48, Michael Maroszek wrote: >> > That's what I also thought when making the PR and therefore I initially >> > went with PHP_INI_ALL. >> > >> > But Tyson made a good point that the curl.cainfo is PHP_INI_SYSTEM and >> we >> > might want to be consistent about modes inside an extension. >> >> Another option might be PHP_INI_PERDIR (for both). Why? Because that's >> what's used for (similar) openssl extension configuration. >> >> ps. anyway, right now I'm on -1 for the new config option. >> >> -- >> Aleksander Machniak >> Kolab Groupware Developer[https://kolab.org] >> Roundcube Webmail Developer [https://roundcube.net] >> >> PGP: 19359DC1 # Blog: https://kolabian.wordpress.com >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >>
Re: [PHP-DEV] [RFC] Add Random Extension (before: Add Random class)
> Could you share some example of where you use it? It looks like mt_rand() could be replaced by mt_rand(0, getrandmax()), but that is not the case, mt_rand() with a specified range is an implementation that generates random numbers until the desired value is obtained, which may unintentionally advance the random state. This can be undesirable for pseudo-random numbers with periodicity. Also, shouldn't compatibility with mt_rand() be maintained? Currently, NumberGenerator\MT19937 is fully compatible with mt_rand(), do We need to drop it? > $random->getNumberGenerator()->generate() to access the raw RNG stream. Indeed. I think nextInt() can be removed from Random, since it currently returns exactly the same value. (However, I think NumberGenerator::generate() should be kept). Regards, Go Kudo 2021年7月6日(火) 23:35 Nikita Popov : > On Fri, Jul 2, 2021 at 3:58 PM Go Kudo wrote: > >> > * The first bit is just clarification. After a cursory look at the >> implementation, my understanding is that the getInt(), shuffleArray() and >> shuffleString() APIs will always produce consistent results on 32-bit and >> 64-bit, as long as your inputs are 32-bit as well (i.e., min/max are 32-bit >> and string is smaller than 4G). Is that correct? The only APIs that would >> exhibit different behavior are nextInt() and getBytes(), right? >> >> Yes. I do not want to break the compatibility of the implementation. I >> would prefer to be able to migrate code that uses the current internal >> state. >> >> > * Looking at the implementation, nextInt() performs a >> 1 operation >> on the RNG result. I assume the motivation is to get back a non-negative >> number. But why do we want that? The "nextInt()" name doesn't really >> indicate that it's a positive number. I think more generally, my question >> here may be "Why does this method exist at all? When would you use it >> instead of getInt()?" >> >> This was to allow for future forward compatibility. When PHP_INT_SIZE >> exceeds 8, the result will be incompatible without bit shifting. This is >> similar to the way mt_rand() does bit shifting now. >> >> However, I can agree that such a day will never come in reality. And as >> the comments on GitHub show, there are ways to keep the values compatible >> even if such a time comes. >> >> After thinking about it for a while, I finally came to the conclusion >> that there is no benefit to this other than to make mt_rand() and >> Random\NumberGenerator\MT19937 directly compatible. >> If compatibility is needed, it can be achieved by bit shifting in the PHP >> code, so direct compatibility is probably unnecessary. I will change the >> implementation and remove this option. >> >> > "Why does this method exist at all? When would you use it instead of >> getInt()?" >> >> The case for this would be if you want to get a raw unrounded random >> number sequence as a number. The situations where this is required would >> certainly be limited, but it would be nice to have. (At least, I know of >> several production codes that use the result of mt_rand() with no >> arguments.) >> > > Could you share some example of where you use it? Maybe that will help > understand the motivation for it. > > Also, I think it's worth pointing out that it's always possible to use > $random->getNumberGenerator()->generate() to access the raw RNG stream. > > Regards, > Nikita > > > * I don't really get why we need RandomInterface. I think if the choice >> is between "final + interface" and "non-final without interface", I'd >> prefer the latter (though I'm also happy with "final without interface"). >> >> I had completely lost my train of thought on this. The interface makes >> the Random class unextensible. I have removed this. >> >> > I'm not entirely happy with the naming. Unfortunately, I don't have >> great suggestions either. I think in your current hierarchy, I would make >> the interface Random\NumberGenerator (with implementation in the >> sub-namespace), rather than Random\NumberGenerator\RandomNumberGenerator. >> >> Deep-rooted problem. For now, I'm going to change RandomNumberGenerator >> to Random\NumberGenerator. It's the best one so far. >> >> >> I continue to be plagued by Valgrind warnings and crashes of Windows ZTS >> builds... >> I'd like to make a voting phase that is fixed ... >> >> Regards, >> Go Kudo >> >> 2021年6月29日(火) 23:01 Nikita Popov : >> >>> On Sat, Jun 26, 2021 at 2:40 AM Go Kudo wrote: >>> Hello Internals. RFC has been reorganized for finalization. https://wiki.php.net/rfc/rng_extension The changes from the previous version are as follows: - Changed again to a class-based approach. The argument can be omitted, in which case an instance of XorShift128Plus will be created automatically. - Future scope was specified in the RFC and the functionality was separated as a Random extension. - Changed to separate it as a Random extension and use the appropriate
Re: [PHP-DEV] [RFC] [VOTE] is_literal
On 05-07-2021 20:14, Craig Francis wrote: > Hi Internals, > > I have opened voting on https://wiki.php.net/rfc/is_literal for the > is-literal function. I am glad to see that the RFC eventually turned out as originally proposed. It is simple and provides clear and strong guarantees about the origins of string data. While it has its limitations I do see the potential it has as a building block for building strong security guarantees in applications. Success of this feature probably depends on it being integrated in frameworks. If I had a vote I would vote along with framework authors. Regards, Dik Takken -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Vote] New in initializers
Le mar. 6 juil. 2021 à 15:38, Nikita Popov a écrit : > On Tue, Jul 6, 2021 at 2:30 PM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> >> > > This is not 100% correct, you can have an attribte #[Foo(Foo::class)] >>> and >>> > > then calling ReflectionAttribute::getArguments would also require to >>> > > resolve the type Foo. So this is not different than what could happen >>> > right >>> > > now already. >>> > >>> > >>> > Despite its name, "::class" doesn't care about class definitions, it >>> > just performs a string substitution based on the "namespace" and "use" >>> > statements in the current file. >>> > >>> > In most cases, that happens entirely at compile time, so the following >>> > two source files compile identically: >>> > >>> >>> Hah, I realized after sending the example was bad :) I should have used >>> an >>> example using actual constants (vs magic ones): >>> >>> #[Foo(Foo::BAR)] >>> >>> This would trigger autoloading and resolving during getArguments() >>> >> >> >> Right! >> >> Extending on my proposal, getUninitializedArguments() could return a >> ReflectionConstant in place of such values. >> > > This doesn't extend to any more complex scenario: It's not just > #[Foo(A::B)], it could also be #[Foo(A::FLAG_1 | A::FLAG_2)] and so on. The > only way to do this is to go all the way back to Dmitry's attribute > proposal (https://wiki.php.net/rfc/attributes) which allows fetching the > AST of attribute arguments. That could represent arbitrary arguments > without evaluating them. (In fact, that proposal also allowed attribute > arguments that PHP cannot constant-evaluate at all.) > > I also think that viewing this as "nested attributes" is not quite the > right way to think about it. Yes, the Assert\All use case is nested > attributes, but that's just a special case. More generally this just allows > you to use an object as an attribute argument, and that object does not > necessarily have to be an attribute itself. To give a silly example, if we > were to write argument and return types as attributes, you could have > something like #[ReturnType(new IntersectionType(Foo::class, Bar::class))], > where IntersectionType is just the representation of a particular type, but > is not (and shouldn't be) an attribute itself. > Types are a good example of a structure that the language already knows how to parse without actually requiring all symbols to be loaded: Foo|Bar doesn't require having both types loaded to work. I think we don't need to account for constants in my scenario. ReflectionAttribute::getUninitializedArguments() would then only replace objects with uninitialized placeholders that represent their class and arguments. That should cover the need.
Re: [PHP-DEV] [RFC] Add Random Extension (before: Add Random class)
> 1st This is to avoid conflicts with the implementation in ext/standard. I don't want to do it this way either, but I have to do it this way. Since random in ext/standard does not use namespaces, I would like to change the ext/standard side. > 2nd Although it goes back quite a long time, this implementation was originally based on an extension I submitted to PECL. https://pecl.php.net/package/orng After I posted this to PECL, I found that an object scope RNG had been proposed in the past in the Internals ML, and there was positive feedback about it. https://externals.io/message/112525 However, the proposal never actually took place. This RFC is a realization of that proposal. Is that what you asked? Regards, Go Kudo 2021年7月6日(火) 22:46 Remi Collet : > Le 26/06/2021 à 02:39, Go Kudo a écrit : > > Hello Internals. > > > > RFC has been reorganized for finalization. > > > > https://wiki.php.net/rfc/rng_extension > > 1st I dislike the name "random_ext", why this "_ext" part ? > > 2nd why not following the standard process ? > > 1/ publish on pecl > 2/ merge in php-src if enough success and good feedback > > > Remi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Add Random Extension (before: Add Random class)
On Fri, Jul 2, 2021 at 3:58 PM Go Kudo wrote: > > * The first bit is just clarification. After a cursory look at the > implementation, my understanding is that the getInt(), shuffleArray() and > shuffleString() APIs will always produce consistent results on 32-bit and > 64-bit, as long as your inputs are 32-bit as well (i.e., min/max are 32-bit > and string is smaller than 4G). Is that correct? The only APIs that would > exhibit different behavior are nextInt() and getBytes(), right? > > Yes. I do not want to break the compatibility of the implementation. I > would prefer to be able to migrate code that uses the current internal > state. > > > * Looking at the implementation, nextInt() performs a >> 1 operation on > the RNG result. I assume the motivation is to get back a non-negative > number. But why do we want that? The "nextInt()" name doesn't really > indicate that it's a positive number. I think more generally, my question > here may be "Why does this method exist at all? When would you use it > instead of getInt()?" > > This was to allow for future forward compatibility. When PHP_INT_SIZE > exceeds 8, the result will be incompatible without bit shifting. This is > similar to the way mt_rand() does bit shifting now. > > However, I can agree that such a day will never come in reality. And as > the comments on GitHub show, there are ways to keep the values compatible > even if such a time comes. > > After thinking about it for a while, I finally came to the conclusion that > there is no benefit to this other than to make mt_rand() and > Random\NumberGenerator\MT19937 directly compatible. > If compatibility is needed, it can be achieved by bit shifting in the PHP > code, so direct compatibility is probably unnecessary. I will change the > implementation and remove this option. > > > "Why does this method exist at all? When would you use it instead of > getInt()?" > > The case for this would be if you want to get a raw unrounded random > number sequence as a number. The situations where this is required would > certainly be limited, but it would be nice to have. (At least, I know of > several production codes that use the result of mt_rand() with no > arguments.) > Could you share some example of where you use it? Maybe that will help understand the motivation for it. Also, I think it's worth pointing out that it's always possible to use $random->getNumberGenerator()->generate() to access the raw RNG stream. Regards, Nikita > * I don't really get why we need RandomInterface. I think if the choice > is between "final + interface" and "non-final without interface", I'd > prefer the latter (though I'm also happy with "final without interface"). > > I had completely lost my train of thought on this. The interface makes the > Random class unextensible. I have removed this. > > > I'm not entirely happy with the naming. Unfortunately, I don't have > great suggestions either. I think in your current hierarchy, I would make > the interface Random\NumberGenerator (with implementation in the > sub-namespace), rather than Random\NumberGenerator\RandomNumberGenerator. > > Deep-rooted problem. For now, I'm going to change RandomNumberGenerator to > Random\NumberGenerator. It's the best one so far. > > > I continue to be plagued by Valgrind warnings and crashes of Windows ZTS > builds... > I'd like to make a voting phase that is fixed ... > > Regards, > Go Kudo > > 2021年6月29日(火) 23:01 Nikita Popov : > >> On Sat, Jun 26, 2021 at 2:40 AM Go Kudo wrote: >> >>> Hello Internals. >>> >>> RFC has been reorganized for finalization. >>> >>> https://wiki.php.net/rfc/rng_extension >>> >>> The changes from the previous version are as follows: >>> >>> - Changed again to a class-based approach. The argument can be omitted, >>> in >>> which case an instance of XorShift128Plus will be created automatically. >>> - Future scope was specified in the RFC and the functionality was >>> separated >>> as a Random extension. >>> - Changed to separate it as a Random extension and use the appropriate >>> namespace. >>> - In order to extend the versatility of the final class, Random, a >>> RandomInterface has been added, similar in approach to the >>> DateTimeInterface. >>> >> >> The updated proposal looks quite nice :) I think this is close to done. >> Some small bits of feedback: >> >> * The first bit is just clarification. After a cursory look at the >> implementation, my understanding is that the getInt(), shuffleArray() and >> shuffleString() APIs will always produce consistent results on 32-bit and >> 64-bit, as long as your inputs are 32-bit as well (i.e., min/max are 32-bit >> and string is smaller than 4G). Is that correct? The only APIs that would >> exhibit different behavior are nextInt() and getBytes(), right? >> * Looking at the implementation, nextInt() performs a >> 1 operation on >> the RNG result. I assume the motivation is to get back a non-negative >> number. But why do we want that? The "nextInt()" name doesn't
Re: [PHP-DEV] [RFC] Add Random Extension (before: Add Random class)
I was late in noticing the email. I'm sorry. > I still feel we should find a better name for them. This is based on Java's Random.nextInt(), which may indeed be confusing. How about generateInt()? > What's the range of its return? It's not clear in the RFC. Currently, there is no way to check this, but we believe that since the RNG implementation is now class-based, there is no need to check this anymore. The size of the RNG to be generated is clear at the time of implementation, and implementing a way to check this would override the method and break consistency. Regards, Go Kudo 2021年7月3日(土) 4:15 CHU Zhaowei : > >> "Why does this method exist at all? When would you use it instead of > >> getInt()?" > >> > > The case for this would be if you want to get a raw unrounded random > number sequence as a number. The situations where this is required would > certainly be limited, but it would be nice to have. (At least, I know of > several production codes that use the result of mt_rand() with no > arguments.) > > These two methods confused me at first as well, but I think it's ok with > me after I check the documentation of mt_rand(), which also supports > calling without range. So, compatibility is one of the reasons why this > method exists, although I still feel we should find a better name for them. > They are too similar now, you won't be able to tell the difference without > looking into the documentation or source code. > > Besides the name issue, I have another question for nextInt(). What's the > range of its return? It's not clear in the RFC. The range of mt_rand() > (without min and max) is 0 to mt_getrandmax(), so how about nextInt()? is > there any equivalent method/constant for it? > > Regards, > CHU Zhaowei > > > >
Re: [PHP-DEV] [RFC] Add Random Extension (before: Add Random class)
Le 26/06/2021 à 02:39, Go Kudo a écrit : Hello Internals. RFC has been reorganized for finalization. https://wiki.php.net/rfc/rng_extension 1st I dislike the name "random_ext", why this "_ext" part ? 2nd why not following the standard process ? 1/ publish on pecl 2/ merge in php-src if enough success and good feedback Remi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Vote] New in initializers
On Tue, Jul 6, 2021 at 2:30 PM Nicolas Grekas wrote: > > > > This is not 100% correct, you can have an attribte #[Foo(Foo::class)] >> and >> > > then calling ReflectionAttribute::getArguments would also require to >> > > resolve the type Foo. So this is not different than what could happen >> > right >> > > now already. >> > >> > >> > Despite its name, "::class" doesn't care about class definitions, it >> > just performs a string substitution based on the "namespace" and "use" >> > statements in the current file. >> > >> > In most cases, that happens entirely at compile time, so the following >> > two source files compile identically: >> > >> >> Hah, I realized after sending the example was bad :) I should have used an >> example using actual constants (vs magic ones): >> >> #[Foo(Foo::BAR)] >> >> This would trigger autoloading and resolving during getArguments() >> > > > Right! > > Extending on my proposal, getUninitializedArguments() could return a > ReflectionConstant in place of such values. > This doesn't extend to any more complex scenario: It's not just #[Foo(A::B)], it could also be #[Foo(A::FLAG_1 | A::FLAG_2)] and so on. The only way to do this is to go all the way back to Dmitry's attribute proposal (https://wiki.php.net/rfc/attributes) which allows fetching the AST of attribute arguments. That could represent arbitrary arguments without evaluating them. (In fact, that proposal also allowed attribute arguments that PHP cannot constant-evaluate at all.) I also think that viewing this as "nested attributes" is not quite the right way to think about it. Yes, the Assert\All use case is nested attributes, but that's just a special case. More generally this just allows you to use an object as an attribute argument, and that object does not necessarily have to be an attribute itself. To give a silly example, if we were to write argument and return types as attributes, you could have something like #[ReturnType(new IntersectionType(Foo::class, Bar::class))], where IntersectionType is just the representation of a particular type, but is not (and shouldn't be) an attribute itself. Regards, Nikita
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
On Tue, Jul 6, 2021 at 2:25 PM Jakob Givoni wrote: > On Tue, Jul 6, 2021 at 10:30 AM Rowan Tommins > wrote: > > > > Hi Mike, > > > > > > > Instead I replied because your email strongly implied (stated?) that > "deprecation required removal" > > > > I stand by that interpretation, which while not universal is very widely > > used, and I think is more useful than a general hint at "bad practice". > > > > You spend most of your e-mail seeming to argue against it, and then seem > > to say that actually you do agree with it after all, and all you're > > saying is that sometimes the deprecation period should be longer: > > > > > > > I am not advocating that. I am advocating we should consider making > it: > > > > > > "features that are strongly discouraged will*probably* be removed in > the next major version, but in some cases may be retained for one or more > major versions." > > > > I'm totally OK with that. > > > > I do think that there should be a clear *plan* for removing each > > deprecated feature, though. That plan might be "deprecate in 8.1, and > > examine prior to 9.0 whether usage has dropped / the alternatives are > > mature / etc". It might flat out be "deprecate in 8.1, but don't remove > > until 10.0". > > > > Otherwise, the message becomes "this feature is kind of bad, and at some > > point we might decide to drop it without further notice, but actually we > > might not, so no hurry to remove it", which I just think isn't that > helpful. > > > > I think it would be very helpful. > I would have loved to know that FILTER_SANITIZE_STRING was not > considered a good choice when I recently researched how to improve an > issue. > Deprecation without a fixed removal version is better than no > deprecation (because removal version was not agreed on). > > Actually I agree with everything that Mike said previously and I > strongly suggest a policy that looks like this: > > Deprecation means no longer encouraged (strongly) and might be removed > in a future (major) version. > Before every new major version, review all deprecated features/usages > and decide with a simple RFC if each of them should be removed, > reviewing the current usage level and migration paths. > > Best, > Jakob > As far as this RFC is concerned (and this is the customary phrasing for all deprecation RFCs), all changes are for deprecation in PHP 8.1 and removal in PHP 9.0. That's the baseline. However, nothing prevents you from starting an RFC prior to the PHP 9.0 release that counters the prior decision and extends the deprecation period for another major version. However, the onus is now on you to argue that something previously deprecated should not be removed (or not be removed yet). If you cannot make a strong argument for that, then the default action is taken. We do still carry a couple deprecations from PHP 5 times around, because actually removing the affected functionality has some technical issues. Regards, Nikita
Re: [PHP-DEV] [Vote] New in initializers
> > > This is not 100% correct, you can have an attribte #[Foo(Foo::class)] > and > > > then calling ReflectionAttribute::getArguments would also require to > > > resolve the type Foo. So this is not different than what could happen > > right > > > now already. > > > > > > Despite its name, "::class" doesn't care about class definitions, it > > just performs a string substitution based on the "namespace" and "use" > > statements in the current file. > > > > In most cases, that happens entirely at compile time, so the following > > two source files compile identically: > > > > Hah, I realized after sending the example was bad :) I should have used an > example using actual constants (vs magic ones): > > #[Foo(Foo::BAR)] > > This would trigger autoloading and resolving during getArguments() > Right! Extending on my proposal, getUninitializedArguments() could return a ReflectionConstant in place of such values.
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
On Tue, Jul 6, 2021 at 10:30 AM Rowan Tommins wrote: > > Hi Mike, > > > > Instead I replied because your email strongly implied (stated?) that > > "deprecation required removal" > > I stand by that interpretation, which while not universal is very widely > used, and I think is more useful than a general hint at "bad practice". > > You spend most of your e-mail seeming to argue against it, and then seem > to say that actually you do agree with it after all, and all you're > saying is that sometimes the deprecation period should be longer: > > > > I am not advocating that. I am advocating we should consider making it: > > > > "features that are strongly discouraged will*probably* be removed in the > > next major version, but in some cases may be retained for one or more major > > versions." > > I'm totally OK with that. > > I do think that there should be a clear *plan* for removing each > deprecated feature, though. That plan might be "deprecate in 8.1, and > examine prior to 9.0 whether usage has dropped / the alternatives are > mature / etc". It might flat out be "deprecate in 8.1, but don't remove > until 10.0". > > Otherwise, the message becomes "this feature is kind of bad, and at some > point we might decide to drop it without further notice, but actually we > might not, so no hurry to remove it", which I just think isn't that helpful. > I think it would be very helpful. I would have loved to know that FILTER_SANITIZE_STRING was not considered a good choice when I recently researched how to improve an issue. Deprecation without a fixed removal version is better than no deprecation (because removal version was not agreed on). Actually I agree with everything that Mike said previously and I strongly suggest a policy that looks like this: Deprecation means no longer encouraged (strongly) and might be removed in a future (major) version. Before every new major version, review all deprecated features/usages and decide with a simple RFC if each of them should be removed, reviewing the current usage level and migration paths. Best, Jakob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Vote] New in initializers
On Tue, Jul 6, 2021 at 12:58 PM Rowan Tommins
wrote:
> On 06/07/2021 11:31, Benjamin Eberlei wrote:
> > This is not 100% correct, you can have an attribte #[Foo(Foo::class)] and
> > then calling ReflectionAttribute::getArguments would also require to
> > resolve the type Foo. So this is not different than what could happen
> right
> > now already.
>
>
> Despite its name, "::class" doesn't care about class definitions, it
> just performs a string substitution based on the "namespace" and "use"
> statements in the current file.
>
> In most cases, that happens entirely at compile time, so the following
> two source files compile identically:
>
Hah, I realized after sending the example was bad :) I should have used an
example using actual constants (vs magic ones):
#[Foo(Foo::BAR)]
This would trigger autoloading and resolving during getArguments()
>
> Short form:
>
> namespace Somebody\Something;
> #[ Foo( Foo::class ) ]
> class Whatever {}
>
> Expanded form:
>
> namespace Somebody\Something;
> #[ \Somebody\Something\Foo( '\Somebody\Something\Foo' ) ]
> class Whatever {}
>
>
> There is no need for the class \Somebody\Something\Foo to actually exist
> in either case, the argument is just a string:
> https://3v4l.org/bgNa2#v8.0.8
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [Vote] New in initializers
On 06/07/2021 11:31, Benjamin Eberlei wrote:
This is not 100% correct, you can have an attribte #[Foo(Foo::class)] and
then calling ReflectionAttribute::getArguments would also require to
resolve the type Foo. So this is not different than what could happen right
now already.
Despite its name, "::class" doesn't care about class definitions, it
just performs a string substitution based on the "namespace" and "use"
statements in the current file.
In most cases, that happens entirely at compile time, so the following
two source files compile identically:
Short form:
namespace Somebody\Something;
#[ Foo( Foo::class ) ]
class Whatever {}
Expanded form:
namespace Somebody\Something;
#[ \Somebody\Something\Foo( '\Somebody\Something\Foo' ) ]
class Whatever {}
There is no need for the class \Somebody\Something\Foo to actually exist
in either case, the argument is just a string: https://3v4l.org/bgNa2#v8.0.8
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Vote] New in initializers
> > I've opened voting on https://wiki.php.net/rfc/new_in_initializers. Voting >> > will close on 2021-07-14. >> > >> > Note that relative to the original RFC, new support is limited to >> parameter >> > default values, attribute arguments, static variable initializers and >> > global constant initializers, and not supported in property initializers >> > and class constant initializers. The discussion thread >> > https://externals.io/message/113347 has some extensive information on >> how >> > we got here. >> > >> >> I voted yes and I'm happy this will come to PHP. >> >> I realized I still have one concern that I want to share here, related to >> attributes: >> The RFC breaks the possibility to parse the arguments of an attribute in a >> generic and safe way. >> What I mean is that right now, attributes can be inspected while the >> corresponding classes are not installed, due eg to a missing optional >> dependency. >> > > This is not 100% correct, you can have an attribte #[Foo(Foo::class)] and > then calling ReflectionAttribute::getArguments would also require to > resolve the type Foo. So this is not different than what could happen right > now already. > Right. Yet this can be easily worked around by using a string literal, so at least this issue can be avoided with a CS fixer when it matters. What you can do is use `ReflectionAttribute::getName()` to filter the > attributes you want to work on and only then call getArguments(). > Yes, my comment is about nested instances, not the root ones. #[Any(new Foo, new Bar)] <= Foo and Bar classes have to be defined, but this should be inspectable without instantiation, like root attributes. > This behavior is what makes attributes truly declarative: one can ignore >> what they don't care about. Extra semantics can be carried out by classes >> without making the related attributes a mandatory dependency. >> >> I think there is a way to preserve this behavior and that we should look >> for it. >> >> If I may propose one: we might add a new >> ReflectionAttribute::getUninitializedArguments() method, that would return >> the same as ReflectionAttribute::getArguments(), except that it would put >> a >> ReflectionAttribute (or similar) instance in place of objects in the data >> structure. As a corollary, we might also want to enforce that only child >> classes of the Attribute class can be nested inside another Attribute (at >> least if we want to reuse ReflectionAttribute as a placeholder.) >> > > A function like this could return all arguments that are not AST Nodes but > "literals" (instances of scalar / array types). > Foo::class or new Foo() are both AST Node types that are resolved the same > way in `getArguments`. > I guess so, but I'm not sure to get the exact point you want to make here :)
Re: [PHP-DEV] Vote!
Hi Daniel, Please create a new email thread, with the tag [VOTE] in the subject along with the name of your RFC: "[VOTE] Add PDO function: mysqlGetWarningCount" Threads with ambiguous titles like this one (subject is just "Vote!") are likely to be overlooked / ignored. It would also have been courteous to send a reminder of the RFC before opening the vote (e.g. "I'm going to start voting next week, any more feedback before then is welcome."). This topic was last discussed, from what I can see, at the beginning of April (2021) so a vote happening now (July 2021) is pretty unexpected. Kind regards, Peter On Tue, 6 Jul 2021 at 10:47, Daniel Beardsley wrote: > I've moved my RFC to the voting phase. > > Voting will be open till 2020-07-21 > > https://wiki.php.net/rfc/pdo-mysql-get-warning-count > > The pull request (with tests) is here: > https://github.com/php/php-src/pull/6677 > > Thanks for your time! > Daniel >
Re: [PHP-DEV] [Vote] New in initializers
On Tue, Jul 6, 2021 at 9:31 AM Nicolas Grekas wrote: > Hi NIkita, > > I've opened voting on https://wiki.php.net/rfc/new_in_initializers. Voting > > will close on 2021-07-14. > > > > Note that relative to the original RFC, new support is limited to > parameter > > default values, attribute arguments, static variable initializers and > > global constant initializers, and not supported in property initializers > > and class constant initializers. The discussion thread > > https://externals.io/message/113347 has some extensive information on > how > > we got here. > > > > I voted yes and I'm happy this will come to PHP. > > I realized I still have one concern that I want to share here, related to > attributes: > The RFC breaks the possibility to parse the arguments of an attribute in a > generic and safe way. > What I mean is that right now, attributes can be inspected while the > corresponding classes are not installed, due eg to a missing optional > dependency. > This is not 100% correct, you can have an attribte #[Foo(Foo::class)] and then calling ReflectionAttribute::getArguments would also require to resolve the type Foo. So this is not different than what could happen right now already. What you can do is use `ReflectionAttribute::getName()` to filter the attributes you want to work on and only then call getArguments(). > This behavior is what makes attributes truly declarative: one can ignore > what they don't care about. Extra semantics can be carried out by classes > without making the related attributes a mandatory dependency. > > I think there is a way to preserve this behavior and that we should look > for it. > > If I may propose one: we might add a new > ReflectionAttribute::getUninitializedArguments() method, that would return > the same as ReflectionAttribute::getArguments(), except that it would put a > ReflectionAttribute (or similar) instance in place of objects in the data > structure. As a corollary, we might also want to enforce that only child > classes of the Attribute class can be nested inside another Attribute (at > least if we want to reuse ReflectionAttribute as a placeholder.) > A function like this could return all arguments that are not AST Nodes but "literals" (instances of scalar / array types). Foo::class or new Foo() are both AST Node types that are resolved the same way in `getArguments`. > > WDYT? > > Nicolas >
[PHP-DEV] Vote!
I've moved my RFC to the voting phase. Voting will be open till 2020-07-21 https://wiki.php.net/rfc/pdo-mysql-get-warning-count The pull request (with tests) is here: https://github.com/php/php-src/pull/6677 Thanks for your time! Daniel
Re: [PHP-DEV] [RFC] [VOTE] is_literal
On Tue, 6 Jul 2021 at 7:38 am, G. P. B. wrote: > Although I think the idea of the feature is useful, > I'm not so sure about the implementation. > [...] > Whereas using a function like concat_literal() which checks that the > inputs are indeed literals provides immediate feedback that the type > constraint is not being violated. Hi George, Thank you for your message. We have provided a userland `literal_concat()` function in the RFC to do exactly what you’re suggesting, while allowing developers to choose to do things like raise exceptions during development/testing, and ignore/log issues when running in production. So you absolutely can use it like that if you want. https://wiki.php.net/rfc/is_literal#support_functions We also agree that a dedicated type would be useful, but as noted by Joe and someniatko, that should come in 8.2 once the function is established (allowing us to potentially build on Intersection Types, and will involve a separate discussion). This is noted under "Future Scope". https://externals.io/message/114835#114847 The only difference is that we decided to allow string concatenation of literals, as we want to provide something that’s usable for everyone immediately, provides the same level of security, and doesn’t require a mass rewriting of existing code. (Which is basically a death sentence for most security-based improvements, as a lot of people won’t have the time/energy to do that. The more automatic security can be, the better, which is why something libraries can implement is ideal). https://wiki.php.net/rfc/is_literal#string_concatenation Excluding concatenation would almost certainly prevent libraries from using this check, simply because developers do use concatenation, which will result in too many invalid errors, requiring them to make substantial/unnecessary changes (i.e. replacing every string concat with `literal_concat()`, or using a special Query Builder for their SQL/HTML/CLI/etc). It’s also worth noting that developers who want to use `strict_types` are probably using static analysis already, where Psalm has just added support for this (thank you Matthew): https://github.com/vimeo/psalm/releases/tag/4.8.0 Thanks, Craig
Re: [PHP-DEV] [RFC] [VOTE] is_literal
On 06/07/2021 07:38, G. P. B. wrote:
This is I think the main issue with the current shape of the proposal.
This implementation will detect certain security issues, but finding the
root cause for them is going to be rather complicated, as the concatenation
operation is basically kicking the can down the road about the
responsibility of checking whether or not the result is a literal.
Whereas using a function like concat_literal() which checks that the inputs
are indeed literals provides immediate feedback that the type constraint is
not being violated.
I still don't follow this reasoning, for the reasons I outlined here:
https://externals.io/message/114835#114868 and again later:
https://externals.io/message/115037#115156
You can write your own concat_literal() function with the current
implementation:
function concat_literal(string $a, string $b): string {
if( ! is_literal($a) || ! is_literal($b) ) {
throw new TypeError;
}
return $a . $b;
}
This does everything a native version would, and can be used in all the
same places.
What it won't do, is tell you when you've forgotten to use it, and used
the normal string concatenation operator - but nor would a built-in
implementation.
Whether "$foo . $bar" is always non-literal, or non-literal only if one
of its operands is, you're going to get an error about a non-literal
string somewhere else in the program, and have to trace back to find
where the "bad" concatenation happened.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
Hi Mike, Instead I replied because your email strongly implied (stated?) that "deprecation required removal" I stand by that interpretation, which while not universal is very widely used, and I think is more useful than a general hint at "bad practice". You spend most of your e-mail seeming to argue against it, and then seem to say that actually you do agree with it after all, and all you're saying is that sometimes the deprecation period should be longer: I am not advocating that. I am advocating we should consider making it: "features that are strongly discouraged will*probably* be removed in the next major version, but in some cases may be retained for one or more major versions." I'm totally OK with that. I do think that there should be a clear *plan* for removing each deprecated feature, though. That plan might be "deprecate in 8.1, and examine prior to 9.0 whether usage has dropped / the alternatives are mature / etc". It might flat out be "deprecate in 8.1, but don't remove until 10.0". Otherwise, the message becomes "this feature is kind of bad, and at some point we might decide to drop it without further notice, but actually we might not, so no hurry to remove it", which I just think isn't that helpful. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Vote] New in initializers
Hi NIkita, I've opened voting on https://wiki.php.net/rfc/new_in_initializers. Voting > will close on 2021-07-14. > > Note that relative to the original RFC, new support is limited to parameter > default values, attribute arguments, static variable initializers and > global constant initializers, and not supported in property initializers > and class constant initializers. The discussion thread > https://externals.io/message/113347 has some extensive information on how > we got here. > I voted yes and I'm happy this will come to PHP. I realized I still have one concern that I want to share here, related to attributes: The RFC breaks the possibility to parse the arguments of an attribute in a generic and safe way. What I mean is that right now, attributes can be inspected while the corresponding classes are not installed, due eg to a missing optional dependency. This behavior is what makes attributes truly declarative: one can ignore what they don't care about. Extra semantics can be carried out by classes without making the related attributes a mandatory dependency. I think there is a way to preserve this behavior and that we should look for it. If I may propose one: we might add a new ReflectionAttribute::getUninitializedArguments() method, that would return the same as ReflectionAttribute::getArguments(), except that it would put a ReflectionAttribute (or similar) instance in place of objects in the data structure. As a corollary, we might also want to enforce that only child classes of the Attribute class can be nested inside another Attribute (at least if we want to reuse ReflectionAttribute as a placeholder.) WDYT? Nicolas
Re: [PHP-DEV] [RFC] [VOTE] is_literal
On Mon, 5 Jul 2021 at 20:15, Craig Francis wrote: > Hi Internals, > > I have opened voting on https://wiki.php.net/rfc/is_literal for the > is-literal function. > > The vote closes 2021-07-19 > > The proposal is to add the function is_literal(), a simple way to identify > if a string was written by a developer, removing the risk of a variable > containing an Injection Vulnerability. > > This implementation is for literal strings ONLY (after discussion over > allowing integers) and, thanks to the amazing work of Joe Watkins, now > works fully with compiler optimisations, interned strings etc. > > Craig > Hi Craig, Although I think the idea of the feature is useful, I'm not so sure about the implementation. I watched the talk you referenced a couple of times at different points in time (the first being a couple of years back), and I fail to see how this RFC is a similar implementation to it. As how they do it at Google is to have it part of the type systems (arguably in a weird way but nonaless), and due to the language being compiled the compiler will just flat out refuse to produce an executable if the types mismatch. >From my understanding, the RFC's implementation is similar to what Google does, which is to "annotate" the string, but without having the guarantees of a compiler to back it up. This approach is totally reasonable for static analysis, as running it is akin to the compilation step in checking the validity. However, having this approach built into the language itself seems rather problematic to me. Ideally we would want to assign a variable to be of 'literal' type to ensure none of the actions applied to it demote it from being a literal, and when such a demotion would occur, for it to TypeError. Due to PHP's nature we cannot do this (yet?), therefore overloading the concatenation operation seems rather unwise. The case where concatenation between a literal and a non-literal happens, without error, is very similar to passing around a nullable type until one function/method/property doesn't accept null where it blows up into your face, and you need to track down where on earth did the null value came from, which might be multiple calls prior. And there has been a hell of a lot of talks/articles/etc. about *not* using nullable types due to this issue. This is I think the main issue with the current shape of the proposal. This implementation will detect certain security issues, but finding the root cause for them is going to be rather complicated, as the concatenation operation is basically kicking the can down the road about the responsibility of checking whether or not the result is a literal. Whereas using a function like concat_literal() which checks that the inputs are indeed literals provides immediate feedback that the type constraint is not being violated. Due to this reason, I'm voting against this proposal. Best regards, George P. Banyard
