Re: [PHP-DEV] [RFC] [VOTE] Add 4 new rounding modes to round() function
I'm sorry for the confusion. I followed the guide for the voting stating that the first voting is primary, and rest are secondary, which don't require 2/3 votes on yes. https://wiki.php.net/RFC/voting#voting As this was my first RFC I was struggling a little bit, because the whole description about RFCs are divided into several pages and in the template there is not really an example for the primary and secondary voting. For the new contributors some things are not entirely clear. Maye we could improve the documentation of the process moving everything to the Git? This could improve the transparency of the whole process and allow for the clearer descriptions by the joint contribution? Kind regards, Jorg
Re: [PHP-DEV] [RFC] [VOTE] Change the edge case of round()
Hi! I've voted no, but only because I think that because this is technically a documented (through RFC) BC break, it should wait for PHP 9, and not for any 8.*. I think so too, it's a frequently used function, and while the argument for the change look convincing, changing it an advanced point version still sounds like not a good idea. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
Am 03.12.23 um 19:34 schrieb Larry Garfield:
On Sun, Dec 3, 2023, at 10:34 AM, Derick Rethans wrote:
On 3 December 2023 14:49:12 GMT, Nikita Popov wrote:
On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote:
Hi all,
I've just opened voting for the final anonymous classes RFC @
https://wiki.php.net/rfc/final_anonymous_classes.
Voting started now, and will run until December 18th 2023, 00:00 GMT.
For the record, I've voted against this proposal because I believe it should
have gone with option 2, that is to *always* make anonymous classes final.
It makes very little sense to me that everyone needs to explicitly mark their anonymous
classes as final just because there is a class_alias loophole that could, in theory, have
been used to extend anonymous classes in the past. Especially given that there is no
evidence of this "feature" being used in the wild (or if there is such
evidence, it was not presented in the proposal).
Regards,
Nikita
I agree with this, and would also say that this RFC is the most thin
one I've seen.
There is no reasoning, or examples, or pretty much anything else in it.
I have also voted no for the same reasons as above. A more fleshed out RFC
that goes default-final (which would then enable the engine optimizations
mentioned) I would probably vote yes for. Though one could debate if that
should be saved for 9.0 just to be safe. (Which I'd also be fine with.)
I also voted NO for the same reason.
But also because I am missing a few things in the RFC.
I am especially missing a reasoning as to why final for anonymous
classes is a thing in the first place. What pain is this RFC adressing?
(Apart from not being able to write `new final class{}`)
Also I'd expect all the relevant information from the discussion to be
in the RFC so that we can figure out what the main points were without
having to dig through Mailinglists or PRs.
Cheers
Andreas
--
,,,
(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/where |
|https://hei.gl/pubkeyandreas |
+-+
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
On Sun, Dec 3, 2023, at 10:34 AM, Derick Rethans wrote: > On 3 December 2023 14:49:12 GMT, Nikita Popov wrote: >>On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote: >>> Hi all, >>> >>> I've just opened voting for the final anonymous classes RFC @ >>> https://wiki.php.net/rfc/final_anonymous_classes. >>> >>> Voting started now, and will run until December 18th 2023, 00:00 GMT. >> >>For the record, I've voted against this proposal because I believe it should >>have gone with option 2, that is to *always* make anonymous classes final. >> >>It makes very little sense to me that everyone needs to explicitly mark their >>anonymous classes as final just because there is a class_alias loophole that >>could, in theory, have been used to extend anonymous classes in the past. >>Especially given that there is no evidence of this "feature" being used in >>the wild (or if there is such evidence, it was not presented in the proposal). >> >>Regards, >>Nikita > I agree with this, and would also say that this RFC is the most thin > one I've seen. > > There is no reasoning, or examples, or pretty much anything else in it. I have also voted no for the same reasons as above. A more fleshed out RFC that goes default-final (which would then enable the engine optimizations mentioned) I would probably vote yes for. Though one could debate if that should be saved for 9.0 just to be safe. (Which I'd also be fine with.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
Am 03.12.2023 um 15:49 schrieb Nikita Popov: For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final. I voted "no" for exactly the same reason. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
On 3 December 2023 14:49:12 GMT, Nikita Popov wrote: >On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote: >> Hi all, >> >> I've just opened voting for the final anonymous classes RFC @ >> https://wiki.php.net/rfc/final_anonymous_classes. >> >> Voting started now, and will run until December 18th 2023, 00:00 GMT. > >For the record, I've voted against this proposal because I believe it should >have gone with option 2, that is to *always* make anonymous classes final. > >It makes very little sense to me that everyone needs to explicitly mark their >anonymous classes as final just because there is a class_alias loophole that >could, in theory, have been used to extend anonymous classes in the past. >Especially given that there is no evidence of this "feature" being used in the >wild (or if there is such evidence, it was not presented in the proposal). > >Regards, >Nikita I agree with this, and would also say that this RFC is the most thin one I've seen. There is no reasoning, or examples, or pretty much anything else in it. cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Change the edge case of round()
On 24 November 2023 00:31:16 GMT, Saki Takamachi wrote: >Hi internals, > >I started voting on my RFC "Change the edge case of round()”. > >Voting will end December 8th, 00:00 GMT. > >https://wiki.php.net/rfc/change_the_edge_case_of_round > >Regards. > >Saki >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: https://www.php.net/unsub.php I've voted no, but only because I think that because this is technically a documented (through RFC) BC break, it should wait for PHP 9, and not for any 8.*. cheers Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
On Sun, Dec 3, 2023, at 16:05, Nicolas Grekas wrote: > Hello Nikita, > >> > I've just opened voting for the final anonymous classes RFC @ >> > https://wiki.php.net/rfc/final_anonymous_classes. >> > >> > Voting started now, and will run until December 18th 2023, 00:00 GMT. >> >> For the record, I've voted against this proposal because I believe it should >> have gone with option 2, that is to *always* make anonymous classes final. >> >> It makes very little sense to me that everyone needs to explicitly mark >> their anonymous classes as final just because there is a class_alias >> loophole that could, in theory, have been used to extend anonymous classes >> in the past. Especially given that there is no evidence of this "feature" >> being used in the wild (or if there is such evidence, it was not presented >> in the proposal). > > You might have missed my message in the discussion thread, > > see https://externals.io/message/121685#121690 > > There is such evidence (not in the RFC though). Thanks, I did indeed miss this. However, I also don't think that a test-only use is particularly compelling. If this were something that Symfony had exposed as a public API promise, we might be caught between a rock and a hard place, but this thankfully doesn't seem to be the case. I think I can fairly confidently say that the ability to extend anonymous classes by abusing class_alias is a bug in the original implementation, rather than an intentional feature. Yes, people do start to depend on bugs if they exist for long enough, but I don't think this means we shouldn't fix them (within the bounds of pragmatism). Regards, Nikita
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
Hello Nikita, > > I've just opened voting for the final anonymous classes RFC @ > > https://wiki.php.net/rfc/final_anonymous_classes. > > > > Voting started now, and will run until December 18th 2023, 00:00 GMT. > > For the record, I've voted against this proposal because I believe it > should have gone with option 2, that is to *always* make anonymous classes > final. > > It makes very little sense to me that everyone needs to explicitly mark > their anonymous classes as final just because there is a class_alias > loophole that could, in theory, have been used to extend anonymous classes > in the past. Especially given that there is no evidence of this "feature" > being used in the wild (or if there is such evidence, it was not presented > in the proposal). > You might have missed my message in the discussion thread, see https://externals.io/message/121685#121690 There is such evidence (not in the RFC though). Nicolas
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
Hi Nikita, For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final. It makes very little sense to me that everyone needs to explicitly mark their anonymous classes as final just because there is a class_alias loophole that could, in theory, have been used to extend anonymous classes in the past. Especially given that there is no evidence of this "feature" being used in the wild (or if there is such evidence, it was not presented in the proposal). Should I amend the RFC, recreating the current poll with three mutually exclusive options (final anonymous classes, final by default without open, final by default with open) instead of just Yes/No (I personally share your PoV, but given the minor pushback received in the last discussion thread I initially decided against it), could that be done without restarting the discussion process? Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
On Sun, Dec 3, 2023, at 11:40, Daniil Gentili wrote: > Hi all, > > I've just opened voting for the final anonymous classes RFC @ > https://wiki.php.net/rfc/final_anonymous_classes. > > Voting started now, and will run until December 18th 2023, 00:00 GMT. For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final. It makes very little sense to me that everyone needs to explicitly mark their anonymous classes as final just because there is a class_alias loophole that could, in theory, have been used to extend anonymous classes in the past. Especially given that there is no evidence of this "feature" being used in the wild (or if there is such evidence, it was not presented in the proposal). Regards, Nikita
Re: [PHP-DEV] [PDO] 2 phase commit
Hi, > Do you have any ideas how to handle this case at the core level in the > regard of php lifecycle? I agree with Kentaro on this. This can be said to be a weakness of two-phase commit itself, but I think it should be addressed in userland or user operations. BTW, I said that I was thinking of implementing two-phase commit in pdo core, but that may be a bit unreasonable. Perhaps because it is not standardized in standard SQL, the method of implementing this function varies from database to database. The steps leading up to the final commit vary greatly depending on the DB. Looking at the current implementation for each DB, it is possible to forcefully create a method in the core, but this will break down when the DB specifications change in the future. Perhaps two-phase commit is a feature that should be implemented in pdo subclasses with "retaining the personality of the DB''. Regards. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] [RFC] Change how JIT is disabled by default
Hi all, I've just opened voting for the "Change how JIT is disabled by default" RFC @ https://wiki.php.net/rfc/jit_config_defaults. Voting started now, and will run until December 18th 2023, 00:00 GMT. Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] [RFC] Final anonymous classes
Hi all, I've just opened voting for the final anonymous classes RFC @ https://wiki.php.net/rfc/final_anonymous_classes. Voting started now, and will run until December 18th 2023, 00:00 GMT. Regards, Daniil Gentili. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
