Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a languageconstructinto a standard function
On Monday, 5 August 2024 at 18:30, Christoph M. Becker
wrote:
> On 05.08.2024 at 18:52, Tim Düsterhus wrote:
>
> > On 8/5/24 14:52, Christoph M. Becker wrote:
> >
> > > Hmm, so far I only had skimmed the RFC and the related discussions, but
> > > now I checked out the suggested implementation[1]. Then I tried to
> > > build with PECL/uopz, and of course that failed because ZEND_EXIT is no
> > > longer there. Okay, quickly drop that usage; build succeeds. Then I ran
> > >
> > > > > uopz_set_return("exit", function () {echo "hello";}, true);
> > > exit;
> > > ?>
> > >
> > > And got
> > >
> > > hello
> > >
> > > Previously, no output was echoed. While that seems to be fixable in
> >
> > Frankly from a userland developer PoV this looks entirely correct: If I
> > override the `exit()` function, then I expect the `exit()` function to
> > be overridden.
>
>
> I should have clarified, that "fixing" means to restore the expected
> behavior of uopz, namely that accidential attempts to override exit with
> `uopz_set_return()` were silently ignored, but unless `uopz.exit=1` is
> set, or `uopz_allow_exit(true)` is called, exit is ignored. Especially
> the latter may be relied upon by tests for legacy code.
>
> Christoph
This sounds like a uopz extension issue that is easily fixed.
I am not sure why we should bend over backwards for extensions that allow to
break usual userland semantics while preventing userland behaviour to be better.
Best regards,
Gina P. Banyard
Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language construct into a standard function
On Monday, 5 August 2024 at 12:04, Derick Rethans wrote: > On Tue, 30 Jul 2024, Christoph M. Becker wrote: > > > On 30.07.2024 at 11:49, Gina P. Banyard wrote: > > > > > I have just opened the vote for the "Transform exit() from a > > > language construct into a standard function" RFC: > > > https://wiki.php.net/rfc/exit-as-function > > > > > > The vote will last for two weeks until the 13th of August 2024. > > > > As userland PHP developer, I always regarded `exit` as a control flow > > instruction (quite similar to `break`), and as such I'm not really in > > favor of converting it to a proper function (especially since it is > > not, because the parantheses could be omitted). > > > Xdebug uses exit for exactly that too. For control flow analysis. And I > also always have considered it to be a control flow instruction. > > I see no benefit in changing it to a function, especially because > there will never be a function "exit" from it, just only an "entry". > This breaks function execution symmetry (and causes issues with Xdebug > when I last tried to make it work with a development branch for this > RFC). > > As the RFC is scarce on mitigations for this, I am currently voting "no" > as I am unsure how certain features in Xdebug could remain working. I > have written to the list on other reasons before > (https://externals.io/message/123277#123450) without a conclusion. > > I'll consider changing it to yes if there is a commitment for addressing > these feature-maintaining-requirements to keep Xdebug working, either > through new APIs (think observer) or other mitigations. > > cheers, > Derick > > -- > https://derickrethans.nl | https://xdebug.org | https://dram.io > > Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support > > mastodon: @derickr@phpc.social @xdebug@phpc.social I still do not comprehend your issue. You can either do stuff at compile time, which has been explained before, or use the function call observer for anything runtime related. The behaviour of exit() is completely observable with the current observer framework, so I don't see why anything else needs to be done. Best regards, Gina P. Banyard
Re: [PHP-DEV] Require C11 in PHP 8.4
On Friday, 2 August 2024 at 14:33, Giovanni Giacobbi wrote: > On Thu, 1 Aug 2024 at 23:57, Ilija Tovilo wrote: > >> [...] >> I started fixing these in a PR [1] which required more changes than >> expected. After a short discourse, we were wondering whether it might >> be better to switch to a newer C standard instead. Our coding >> standards [2] currently specify that compiling php-src requires C99. >> The Unix installation page on php.net [3] claims it is ANSI C, which >> is certainly outdated. There have been suggestions to require C11 for >> a while, which should be well supported by all compilers shipped with >> maintained distributions. > > It feels wrong to raise such an important requirement that might affect a lot > of people, including maintainers of extensions, for just one specific > problem, and 99% of the codebase would still be C99 compliant. > > I quickly put together an alternative PR (#15202) with a slightly different > approach, just as a proof of concept. The idea is to move all the global > typedefs in a new include header "zend_types_defs.h" (but also > zend_portability.h can be reused for this purpose, as all the relevant files > already include it). > > While putting together that PR, I had the feeling that this typedef > redefinition problem is in reality hiding some smelly design of header files. > So maybe, rather than requiring a compiler more tolerant to poor code, we > should rather focus on getting the design right. I would like to see actual factual data rather than "vibes" as to how this would cause issues with third-party extensions. php-src is not C99 pedeantic compliant and we do use GCC extenstions. I do agree that maybe we should go back to fixing headers, but considering the drama this caused 18 months ago I do not know who here has the motivation to do this. Ideally I feel we should target C17 as it is a "bug fix" release of C11, but this might be impossible due to old compilers still being the default on LTS Distributions. The main benefit of C11/17 in the long run are atomics, that we kinda use already anyway. Moreover, as someone that has written an extension that has some usage, when I go back to it, I'd rather like to be able to use features from C23 than be stuck on C99, but that is just me. Best regards, Gina P. Banyard >
Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
On Friday, 19 July 2024 at 19:39, Gina P. Banyard wrote: > Hello internals, > > I have opened the vote for the mega deprecation RFC: > https://wiki.php.net/rfc/deprecations_php_8_4 > > Reminder, each vote must be submitted individually. 2 days late but I have now closed the vote for all the RFC proposals. The ones that have been accepted will be implemented in due course. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language construct into a standard function
On Tuesday, 30 July 2024 at 13:47, Christoph M. Becker wrote: > Hi Gina! > > On 30.07.2024 at 11:49, Gina P. Banyard wrote: > > > I have just opened the vote for the "Transform exit() from a language > > construct into a standard function" RFC: > > https://wiki.php.net/rfc/exit-as-function > > > > The vote will last for two weeks until the 13th of August 2024. > > > As userland PHP developer, I always regarded `exit` as a control flow > instruction (quite similar to `break`), and as such I'm not really in > favor of converting it to a proper function (especially since it is not, > because the parantheses could be omitted). You are not the first person to mention this. I don't have any plans on doing anything else to exit, but I never really considered it to be a control flow instruction, but that is maybe just me. > > Would that RFC imply that I would need to write `\\exit` or have a `use exit` > clause to avoid dynamic namespace lookup? If so, I would be even > less in favor of that change. No, since the new implementation where the token is preserved this is not needed. You cannot define the function in a namespace, nor disable it, nor use it as a goto label. The one benefit of having it become a proper function which can also be used as a statement is: - Using named arguments - Passing it to callable parameters - Usual type juggling semantics > > I do understand your point about the type juggling semantics, but I > might have addressed that differently. I almost always use `exit` > without argument (and if, only with an int), and `die` always with a > string (and only for quick experiments), and I figure that this might be > what most contemporary code does (at least, I hope that the > `do_something() or die()` times have long gone). As such, having `exit` > and `die` as alias could be changed, sticking with `exit` as a control > flow instruction, and having `die` as proper function (which could even > be implemented in userland), where exit would allow an optional int > argument (like `break`), and die() a required string argument. Of > course, this would be a much bigger BC break, but it seems to me the > cleaner solution. This might be a good idea in the long term to properly split exit and die and have them take only integers and string respectively, but I am not going to personally bother with this, even if I think this is a good idea. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] [VOTE] Make the GMP class final
On Saturday, 13 July 2024 at 16:05, Gina P. Banyard wrote: > Hello Internals, > > I have just opened the vote for the "Make the GMP class final" RFC: > https://wiki.php.net/rfc/gmp-final > > The vote will last for 2 weeks from today July 13th 2024 to July 24th 2024. > > Best regards, > > Gina P. Banyard The RFC has unanimously been accepted, with 28 votes in favour. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
On Friday, 26 July 2024 at 08:09, Peter Stalman wrote: > On Thu, Jul 25, 2024 at 11:35 PM Peter Stalman wrote: > >> If their learning insticast > > *instincts. > > I should also clarify, I'm not against deprecations in general. However, the > benefits should outweigh the costs. If something is getting unmaintainable, > no longer supported, inherently insecure etc, those are all good reasons. > `password_hash` as mentioned was a great addition, and should/did solve this > very issue. Even someone reading a blog tutorial from 11 years ago would be > able to see this used properly. > > But md5/sha1 are not bad functions, they do *exactly* what they say on the > box. Being able to do the exact same thing by spelling the function slightly > differently isn't even deprecating them, just deprecating an alias. They're > only *bad* if used in a *bad way*, and that to me is not enough of a reason. Stephen Rees-Carter, a security expert that has performed countless security audits on Wordpress and Laravel websites, would like to disagree with the fact that it is not enough of a good reason. [1] A warning on a documentation page is useless, as nobody is forced to read it. Yet again the PHP community doesn't care about security of its users, current and future, and just prefers the convenience of needing to type less characters and not go back fix some code for better design. I am not sure why I was expecting something else, but I guess I am just disappointed. I suppose we are truly becoming Oracle. Sincerely, Gina P. Banyard [1] https://x.com/valorin/status/1816593881791860963
Re: [PHP-DEV] Add tidyNode::getNextSibling() and tidyNode::getPreviousSibling()
On Sunday, 21 July 2024 at 12:24, Niels Dossche wrote: > Hi internals > > I opened a PR to add the getNextSibling() and getPreviousSibling() methods to > the tidyNode class. > As the class is final, this has no BC break concerns. > > The reason for adding this is that it's inconvenient to walk the tree solely > using the existing getParent() method and ->child property. > > Since it's a tree anyway, methods to obtain the previous or next sibling are > natural en convenient. > > Just sending this mail to see if anyone objects to this. > PR link: https://github.com/php/php-src/pull/15047 > > Kind regards > Niels I think this makes sense and is a nice convenience addition. Best regards, Gina P. Banyard
[PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
Hello internals, I have opened the vote for the mega deprecation RFC: https://wiki.php.net/rfc/deprecations_php_8_4 Reminder, each vote must be submitted individually. Best regards, Gina P. Banyard
Re: [PHP-DEV] Optional constructor body
On Thursday, 18 July 2024 at 19:23, Tim Düsterhus wrote: > On 7/18/24 16:03, Lily Bergonzat wrote: > > > I feel like the more substantial one would be more likely to break > > stuff, compared to the minor one, and so I don't see why the minor one > > would be refused? > > > There is no such thing as a minor syntax change. Any changes to the > syntax has consequences for all the downstream tools trying to > understand PHP. This includes IDEs, static analyzers, code formatting > and linting tools, which would all need to be updated to understand the > new syntax. Furthermore the syntax would need to be documented and > translated within the PHP documentation. > > That's quite a bit of effort to save a single character per class > definition. In practice it will be even fewer, because not every class > will have an empty constructor. Also whenever a class gets a non-trivial > constructor in the future, the diff would not just consist of inserting > the new code into the body, but also replacing the semicolon by braces, > making the diff less readable. > > I do not think this is worth it. > > Best regards > Tim Düsterhus I am also of the same opinion. The benefit of this is marginal. And if this requires a semicolon, the benefit is even lower by effectively just typing one less character. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Tuesday, 25 June 2024 at 15:36, Gina P. Banyard wrote: > Hello internals, > > It is this time of year again where we proposed a list of deprecations to add > in PHP 8.4: > > https://wiki.php.net/rfc/deprecations_php_8_4 > > As a reminder, this list has been compiled over the course of the past year > by various different people. > > And as usual, each deprecation will be voted in isolation. > > We still have a bit of time buffer, so if anyone else has any suggestions, > they are free to add them to the RFC. > > Some should be non-controversial, others a bit more. > If such, they might warrant their own dedicated RFC, or be dropped from the > proposal altogether. > > > Best regards, > > Gina P. Banyard Hello internals, It's been a bit over 3 weeks since the discussion started, and I intend to open the vote tomorrow. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers
On Thursday, 4 July 2024 at 14:52, Gina P. Banyard wrote: > Hello internals, > > I would like to formally open the discussion on an RFC I've been working on > for the past year: > https://wiki.php.net/rfc/container-offset-behaviour > Hello internals, Ilija did a review of the RFC and pointed out some good questions and remarks. I've clarified, and amended the implementation, that ArrayAccess extends DimensionReadable, DimensioWriteable, and DimensionUnsettable. I've added to the RFC the deprecation of using integer offsets when using ArrayObject with a backing object, as it turns out supporting this adds a lot of complexity in the engine that would be great to remove. One of the new warnings the RFC introduces is when using a bogus value as a container in isset()/empty() other than `null` which shortcuts. This shouldn't cause many issues, except possibly if the container is `false`, as it may be the result from an internals function call which returns false on failure instead of null. The question is if `false` should have the same exemption as `null`? The behaviour around the increment and decrement operators is slightly unfortunate. Incrementing an array offset or object property is treated more like a read-write operation, however, due to the lack of VM opcodes, it is treated like a fetch for object offsets. After discussion with Ilija it seems wise to make this an Error for now so that we can support it properly in the future, and have the increment observable via the offsetSet() method. There are still a couple of questions around the behaviour of ArrayObject with property hooks that I need to look into, especially around the current ArrayObject behaviour with ignoring the __set() and __get() magic methods. The final question, which is somewhat tricky, is how to deal with auto-vivification? The gist can be explained with the following code: $obj = new Vector(); $ref = &$obj[0]; var_dump($ref); $obj[1][] = 'append'; $obj[2][50] = 'set-to-offset'; For arrays, $ref would be NULL And when nesting them, the "null" auto-magically becomes an array. However, for objects it is not clear what to do, if the fetch() method creates an object, then the initial $ref would already have a auto-vivified container. However, if NULL is returned, then the nested append and offset write would not auto-vivify a nested Vec container, but a standard PHP array. I currently have a crude prototype where, in the nested dimension case, I instantiate a new object of the same type, but this doesn't call the constructor (which I could do), but passing arguments to it is impossible. Another solution is to add another interface, e.g. Autovivificapable, which would define an autovivify() method which would be called in those instances. Does anyone have any opinions about this? I have also slightly amended the RFC and added a BC break recap section. Reminder, the RFC on the Wiki is located here: https://wiki.php.net/rfc/container-offset-behaviour And on GitHub here: https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Monday, 8 July 2024 at 04:04, Juliette Reinders Folmer wrote: > On 2-7-2024 20:05, Gina P. Banyard wrote: >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer >> wrote: >> >>> * While a number of proposals include an impact analysis (thank you!), a >>> significant number of the proposals don't. >>> It would be appreciated if for those proposals which aren't removing >>> unused/unusable functionality, some sort of impact analysis was added. >> >> You will need to clarify which ones you are talking about. >> These "bulk removal" RFCs are written by various authors over the course of >> a year, and might not have been looked at for 9+ months. > > I'd suggest for an impact analysis/expected impact statement to be added to > the following deprecation proposals: I am going to start this reply with the following: An impact analysis showing a large impact to userland, is not in itself, an argument against a deprecation. What an impact analysis helps to determine is the length of the deprecation and the timeline for removal. It is getting exhausting to need to provide this, when what it is, is me asking Damien to check usage on the corpus of over 3100 projects, some open source (such as Wordpress, Drupal, OSS accounting software, etc.), top 1000 composer packages, and the private codebases he has access via his company, using his Exakat static analysis tool. [1] The corpus is 160 MLOC (1.2 Billion tokens), 1.4 M files and as already mentioned over 3100 distinct projets. But his tool will sometimes report duplicates, and has outdated versions which might not be affected by the issues anymore. One reason is that some projects inline composer dependencies, and unless I do a painstaking manual review I cannot narrow this down. Especially as it takes time to run the analysis on the corpus, and if I don't ask the precise question I don't get all the relevant stats. So every stat is a conservative approximation. We don't decide to deprecate and remove things for the fun of it. But if something is misleading, badly designed, dangerous, has a security risk, or causes issues it should be deprecated. It is my belief that it does not matter if this affects 10, 10 000, or 10 000 000 codebases. However, how and when we remove this, yes this is affected by the usage. > * session.sid_length and session.sid_bits_per_character Auditing INI setting usages is effectively impossible with Exakat. Misusing these settings can lead to security issues, and the new values will match the existing defaults. I would guess that the majority of users don't even know about this setting and thus are not affected. Similarly, it seems likely that application developers are also not aware of it, causing applications to break if a hosting provider would adjust these settings. For example: if the application expects it to be a specific format, which is defined in the database schema. Considering the above, these INI settings should be removed and deprecated, regardless of impact. > * xml_set_object() and xml_set_*_handler() with string method names This behaviour is unintuitive and breaks all usual language semantics. This should be deprecated and removed regardless of impact. But when I was working on this I had asked Damien to run some analysis with Exakat and found 66 projects. To which I have sent PRs to some to remove the usage, which is extemely simple to do. To clarify the rationale, the following code is ambiguous: `xml_set_element_handler($p, 'strrev')` It either calls the \strrev() string function, or a method called `strrev` on the object provided by a call to `xml_set_object()`. This is going to be the logic as of PHP 8.4 after some refactoring I did last October. In the current released versions it is even more ambiguous, as the object provided by xml_set_object() could be passed *after* setting the string callable. This behaviour is totally unintuitive, so regardless of the impact it should be removed. > * Deprecate proprietary CSV escaping mechanism This is a follow-up on an RFC whose first step was implemented in PHP 7.4. (https://wiki.php.net/rfc/kill-csv-escaping) The first step was implemented (https://github.com/php/php-src/pull/3515) without a vote being held following the discusion on internals: https://externals.io/message/103268 This routinely bites people, and we still get issues about people being confused about this parameter. We really should address this, and not wait yet another 5 years for complaints to once again be raised before we take any action. > * Deprecate strtok() function Symfony agrees with the rationale provided by the RFC and has banned the function from their project: https://github.com/symfony/symfony/issues/57542 This seems to indicate that the rationale around it is sound. But just for the sake of it, I asked Damien, and I don't
[PHP-DEV] [RFC] [VOTE] Make the GMP class final
Hello Internals, I have just opened the vote for the "Make the GMP class final" RFC: https://wiki.php.net/rfc/gmp-final The vote will last for 2 weeks from today July 13th 2024 to July 24th 2024. Best regards, Gina P. Banyard
Re: [PHP-DEV] Breaking change of rounding behavior in PHP 8.4
On Friday, 12 July 2024 at 12:24, Christoph M. Becker wrote: > Hi all, > > there has been a "small" change in the rounding logic of > _php_math_round()[1] a couple of months ago. A respective ticket, > claiming the new behavior would be a bug[2] had been filed a while ago > without proper triage so far. I'm bringing this to your attention, > because I'm afraid that there will be (many) more bug reports about this > in the future (note that the change only affects master, and only PHP > 8.4.0alpha1 has been released yet, so it is probably not widespreadly > tested yet). At the very least we should be sure that we want to keep > this change, and document it well, to avoid discussions in every filed > ticket. > > My personal stance on this is simple: floating point arithmetic is not > exact per se, and changes to how PHP handles the details should only be > introduced, if they clearly improve things. This change apparently > improves some cases, but worsens others. Thus, I think the change > should better be reverted, and if at all, postponed to PHP 9, since I > neither regard this change as bug fix nor as a feature. > > What do you think? > > [1] https://github.com/php/php-src/pull/1 > > [2] https://github.com/php/php-src/issues/14332 I agree, this situation is extremely suboptimal. My understanding as to why people declined the "Change the edge case of round()" RFC [1] was because they were worried about the silent change in behaviour. However, most people seem to have missed the fact, myself included, that regardless of it being accepted or not there would have been changes to the behaviour. As such we have the worst of both worlds, continuing to have incorrect floating point semantics for people that rely on proper IEEE 754 floating points, and yet we still have a silent change in behaviour due to the partial bugfix. Moreover, these fixes made the implementation of round() more complicated, for marginal benefits IMHO. Best regards, Gina P. Banyard [1] https://wiki.php.net/rfc/change_the_edge_case_of_round
Re: [PHP-DEV] Re: [RFC] [Discussion] Fix up BCMath Number Class / Change GMP bool cast behavior
On Wednesday, 10 July 2024 at 07:35, Saki Takamachi wrote: > Added one more change to the RFC. > > Currently, there is no other expression for comparison in PHP called "comp”. > The expression "cmp" is mainly used for functions, and the expression > "compare" is used for class methods. > > e.g. > https://www.php.net/manual/ja/splpriorityqueue.compare.php > https://www.php.net/manual/ja/collator.compare.php > > Therefore, follow these conventions and rename `comp()` to `compare()`. Thank you, I am happy will all the provided amendments now! Best regards, Gina P. Banyard
Re: [PHP-DEV] [low priority] WeakMaps with scalar keys
On Wednesday, 10 July 2024 at 18:34, Rob Landers wrote: > Hello internals, > > I know now that some of you are swamped getting ready for 8.4, so I want to > be clear that this will be an 8.5+ thing. I am simply sending it to the list > in case anyone wants to discuss it, burn it with fire, give it a gold star, > or ignore until later. > > Currently, a WeakMap may only have object keys, and this logically makes a > lot of sense. However, there are cases where you want to reference an object > by a value but if the value is no longer referenced, no longer need it. A > good example of this might be used in dependency injection containers, lookup > tables for value objects, etc. > > I'd like to propose a ReverseWeakMap where the keys must be scalar, and given > an object as the value. Once the value is no longer referenced, the key and > value is removed from the ReverseWeakMap. Isn't this use case already solved with WeakReferences? https://www.php.net/manual/en/class.weakreference.php Best regards, Gina P. Banyard >
Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers
On Wednesday, 10 July 2024 at 16:22, Levi Morrison wrote: > > Everything considered, I still do not think changing the name of the > > append() method is a good idea, will it hurt adoption in the short term for > > some classes, yes, but I prefer this than having a large part of the > > ecosystem needing to create an alias just for some weird cases. > > > I don't fully understand the issue with aliases. Could you elaborate > on that? Would calling the method instead of direct aliasing avoid > whatever the issue is? I don't think this would solve the issue, as it is not required for a child class that extends said method to call the parent. Let's use a class that extends SplObjectStorage as an example: https://3v4l.org/l913b Our custom class overwrites the behaviour of the contains() method without calling the parent method. As such, the behaviour of isset() becomes incorrect. And even if we make offsetExists() call the contains() method, nothing actually prevents the child class from overwriting the offsetExists() method instead of the contains() one. In which case, the contains() method would still be the original SplObjectStorage one. One could also just extend both methods and have them differ in implementations. I really believe there isn't a good way to solve this problem other than not having any aliases within class methods. Best regards, Gina P. Banyard
Re: [PHP-DEV] Negatively Voted Notes
On Wednesday, 10 July 2024 at 15:18, Derick Rethans wrote: > Hi! > > There are currently nearly 2 notes in the documentation, with many > having a very high negative rating. > > For example, there are: > > 1131 notes older than a year, with a rating less than -10 > 2339 notes older than a year, with a rating less than -5 > 5761 notes older than a year, with a rating less than -1 > > The worst offender is: > > https://www.php.net/manual/en/features.cookies.php#128286 with -159 (not sure > why the website says -153) > https://www.php.net/manual/en/language.attributes.overview.php#126887 with > -104 > > We discussed this during one of our foundation meetings, and we propose: > > - to delete all notes with a rating less than -5 that are older than a > year. > - come up with a plan to crowd source going through the other thousands > of notes to see if they need to be deleted or integrated into the > actual text. Each documentation page now has a link to the XML source > (such as https://github.com/php/doc-en/blob/master/language/attributes.xml) > > Comments? As one of the primary persons that tries to triage new notes, I am strongly in favour. Unrelated, it would be very nice if we could improve the spam filters for user notes somewhat, but this is unrelated to removing unpopular votes. One question, should this possibly become a monthly cron job that checks for the user notes and removes those that fall below the above criterias? Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers
Everything considered, I still do not think changing the name of the append() method is a good idea, will it hurt adoption in the short term for some classes, yes, but I prefer this than having a large part of the ecosystem needing to create an alias just for some weird cases. Best regards, Gina P. Banyard [1] https://www.php.net/manual/en/splobjectstorage.offsetexists.php [2] https://3v4l.org/E8BcK
Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers
On Thursday, 4 July 2024 at 14:52, Gina P. Banyard wrote: > Hello internals, > > I would like to formally open the discussion on an RFC I've been working on > for the past year: > https://wiki.php.net/rfc/container-offset-behaviour > > As DokuWiki is a bit of a faff at times, the Markdown sources are available > on GitHub: > https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md I have more or less finalized the implementation of the object handler part. The JIT works, and my minimal opcache changes seem to not make everything crash. I have added one tiny subsection to the RFC about the removal of the zend_class_arrayaccess_funcs struct: https://wiki.php.net/rfc/container-offset-behaviour#removal_of_the_zend_class_arrayaccess_funcs_struct_and_ce_pointer One related issue that I found while working on this RFC is related to ext/phar: https://github.com/php/php-src/pull/14503 A PharFileInfo extends SplFileInfo and supports directories, which SplFileInfo does not. But Phar also allows the user to set the file info class via the setInfoClass() method. This method takes any SplFileInfo based class, such as SplFileObject. Thus, there is currently a bug in the extension where isset() will return true about being able to access a string offset that points to a directory but SplFileObject will throw a LogicException that it cannot be used with a directory. There are two-way to fix this issue, in my PR I went with the solution to return false for the has_dimension handler on directories if the info class is not based on PharFileInfo, or we could remove support for setting info classes that are not based on PharFileInfo. Let me know what you prefer, as my current implementation is based on the above PR to fix the Phar behavioural changes. Moreover, I know the traffic on the list has been pretty high, but I do intend to have this RFC up for voting for inclusion in PHP 8.4, and I'm not exactly sure how I am meant to interpret the lack of responses. Best regards, Gina P. Banyard
Re: [PHP-DEV] [Initial Feedback] Typed Arrays
On Tuesday, 9 July 2024 at 18:50, Richard Miles wrote: > I’ve asked for karma three separate times in this feed alone and it’s pretty > unclear who has that > ability, my apologies for assuming. Since you responded to that message > specifically, I figured you were a karma granter. Probably because this is not how one asks for karma. > Get wiki RFC karma (this is only required if you don't have a VCS account for > php.net. PHP developers can log on with their credentials and already have > the necessary karma to create RFCs): > > - Register for a wiki account at https://wiki.php.net/start?do=register. > - Email internals@lists.php.net requesting RFC karma for your wiki account. > In the email, remind people about the RFC you plan to create. Note that RFC > karma does not automatically give you karma to vote. See > https://wiki.php.net/rfc/voting#rfc_proposer The implication, that seemingly every other person has managed to do, is to send a NEW email thread. The traffic of the list is extremely high at the moment, and the handful of people that can grant karma do not have the time to sift through every single random email. > This just differs from other advice already given and the online how-to page, > but seriously > I'll just get started if thats what needs to happen. You have this opinion > with past experience > granted, but your not really giving practical feedback on why this > implementation is poor. The how-to page *explicitly* says: > Consider whether the feature concept should be voted on before you invest > time in implementation. > Or perhaps an implementation is needed to show the feature is feasible; in > this case, make it clear whether or not the current implementation is being > voted on. For a lot of large features, like what you are proposing, one needs some sort of implementation to even determine the feasibility. I have barely read the thread, but I have serious doubts that you understand the complexity of the task at hand, as you are far from the first one to propose this nor have a go at this. Moreover, considering the volume of the list and RFCs, any RFC that is just about syntax is something that I personally will just vote no without reading as I have, frankly, more pressing things to do. Your RFC and proposal would have way more discussion if you were not proposing this when feature freeze is fast approaching and people are trying to wrap up RFCs they have worked on for the past year. For the sake of your proposal, I would seriously reconsider proposing this prior to September. Sincerely, Gina P. Banyard >
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Friday, 5 July 2024 at 18:11, Claude Pache wrote: > * For each deprecation, it would be nice to provide explicitly the text of > the deprecation notice so that we can guarantee that it will be helpful for > users, see https://github.com/php/php-src/issues/14320 Considering that until recently, [1] there was no way to provide a message for functions that were deprecated, this was not a consideration. We are adding more useful messages for prior deprecations in a PR right now, [2] but the format of it hasn't been finalized yet, thus I don't think adding it to the RFC at this point is useful. This is something to take into account for next year's RFC, but the implementation of those deprecation is expected to have more useful messages. > * I don’t see the point of deprecating DOMImplementation::getFeature() > instead of just removing it? “DOMImplementation::getFeature() is deprecated, > throw manually an Error exception instead.” Just removing it makes sense, I'll talk to Niels about it, to change what the vote is actually about. Best regards, Gina P. Banyard [1] https://wiki.php.net/rfc/deprecated_attribute [2] https://github.com/php/php-src/pull/14750
Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers
On Sunday, 7 July 2024 at 22:01, Nicolas Grekas wrote: > I don't see any mention of Stringable objects in the RFC. Can you please > describe how they behave when used as string indexes, and if you're proposing > any changes for them Hello Nicolas, All objects behave the same for string offset, i.e. they are invalid and will throw an Error. This is described in the "Invalid offsets" subsection of the "Strings" section. [1] And I am not proposing any changes to them. Best regards, Gina P. Banyard [1] https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md#invalid-offsets-1 >>
[PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers
Hello internals, I would like to formally open the discussion on an RFC I've been working on for the past year: https://wiki.php.net/rfc/container-offset-behaviour As DokuWiki is a bit of a faff at times, the Markdown sources are available on GitHub: https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md The implementation is basically done, other than some mysterious JIT issues that I haven't been able to pinpoint yet. Best regards, Gina P. Banyard
Re: [PHP-DEV] Bumping minimum Apache version to 2.4
On Saturday, 29 June 2024 at 23:58, Peter Kokot wrote: > Hello, > > Perhaps you're not aware that the PHP build system currently still > supports building apache2handler SAPI for Apache 2.0 and 2.2 branches. > Apache 2.2 has been marked as EOL in December 2017 and doesn't receive > security patches. Also, most Linux distributions and packages mostly > support 2.4 as minimum by now. > > See: > https://forum.apachehaus.com/news-general-discussion/apache-2-2-users-your-time-is-running-out/ > > In this pull request, support for Apache 2.0 and 2.2 is being removed: > https://github.com/php/php-src/pull/14664 > > In Autotools build system, there isn't much changed except the version > is checked, on Windows there will be configure option > --enable-apache2-2handler removed and --enable-apache2-4handler > becomes an alias of --enable-apache2handler configure option. > > Let me know if you find any server that can't or hasn't been upgraded > to Apache 2.4 yet and if this should be postponed after PHP 8.4, > otherwise merge is on its way for PHP 8.4. I am also in favour of removing support for this in PHP 8.4. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Tuesday, 25 June 2024 at 15:36, Gina P. Banyard wrote: > Hello internals, > > It is this time of year again where we proposed a list of deprecations to add > in PHP 8.4: > > https://wiki.php.net/rfc/deprecations_php_8_4 > > As a reminder, this list has been compiled over the course of the past year > by various different people. > > And as usual, each deprecation will be voted in isolation. > > We still have a bit of time buffer, so if anyone else has any suggestions, > they are free to add them to the RFC. > I have added a section to deprecate the SOAP_FUNCTIONS_ALL constant: https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_soap_functions_all_constant_and_passing_it_to_soapserveraddfunction Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer
wrote:
> On 25-6-2024 16:36, Gina P. Banyard wrote:
>
>> Hello internals,
>>
>> It is this time of year again where we proposed a list of deprecations to
>> add in PHP 8.4:
>> https://wiki.php.net/rfc/deprecations_php_8_4
>> As a reminder, this list has been compiled over the course of the past year
>> by various different people.
>>
>> And as usual, each deprecation will be voted in isolation.
>>
>> We still have a bit of time buffer, so if anyone else has any suggestions,
>> they are free to add them to the RFC.
>>
>> Some should be non-controversial, others a bit more.
>> If such, they might warrant their own dedicated RFC, or be dropped from the
>> proposal altogether.
>>
>> Best regards,
>>
>> Gina P. Banyard
>
> I've read through the complete set of proposals and have the following
> observations:
>
> * While a number of proposals include an impact analysis (thank you!), a
> significant number of the proposals don't.
>
> It would be appreciated if for those proposals which aren't removing
> unused/unusable functionality, some sort of impact analysis was added.
You will need to clarify which ones you are talking about.
These "bulk removal" RFCs are written by various authors over the course of a
year, and might not have been looked at for 9+ months.
> * DomDocument and DomEntity properties section: the text seems to contradict
> itself - the proposal seems to suggest to soft-deprecate something which is
> already soft deprecated. Some clarification of what the actual proposal is,
> would be helpful.
Those properties have been soft deprecated for a long time, the proposal is to
formally deprecate them.
I've clarified this.
> * `xml_set_object()` section: the mitigation path for this deprecation is
> unclear and more so, it is unclear as of which PHP version the mitigation
> path is available (if there are restrictions). It would be helpful if some
> example code was added to show the mitigation path more clearly.
The migration path is available since at least PHP 5.3, probably even longer.
Instead of calling xml_set_object() with an object $obj, and e.g.
xml_set_default_handler() with a string corresponding to the name of a method
of $obj,
you should set the handler with a proper callable, i.e. using [$obj,
'methodOfObj'] as the handler.
> * CSV escaping section: please make it explicit which functions will be
> affected by this proposal.
Done.
> * `file_put_contents()` section: please make the mitigation path explicit
> (which I presume would be something along the lines of `file_put_contents(
> $filename, implode('', $data) )` ?)
Done.
> Other than that, I join the previously voiced objections to the deprecation
> of `uniqid()`, `md5()`, `sha1()`, `md5_file()`, `sha1_file()`.
> While I acknowledge that these functions _can_ be used inappropriately for
> security-sensitive code, which should use alternative methods, these
> functions have perfectly valid use-cases for non-security-sensitive code and
> the impact of the BC-break of deprecating and eventually removing these
> methods can, IMO, not be justified.
>
> Keep in mind that while "we" know and understand that deprecations are not
> errors, end-users often don't and particularly for open source projects, this
> means that in practice these deprecations will need to be addressed anyway to
> reduce the noise of users opening issues about them, which without a clear
> path to removal of the functions, will, in a lot of cases, mean adding the
> `@` operator to all uses.
If I may be a bit cheeky, if we consider that userland does not understand that
deprecations are not errors, how can we trust them to use the 5 aforementioned
functions correctly?
Especially as there are more appropriate replacements available.
> Regarding the deprecation of using `E_USER_ERROR` in `trigger_error()`: there
> are errors which should never be caught and using `trigger_error()` with
> `E_USER_ERROR` is appropriate for those.
>
> The fact that execution can be returned to the code via `set_error_handler()`
> returning `true` sounds to me like a bug which should be fixed, rather than
> disabling the functionality for userland code to hard exit with an error when
> deemed appropriate.
In that case, calling exit() with a string will provide you more consistent
behaviour, and also run destructors and finally blocks.
The main motivation to remove it is to curtail the usage of the bailout
mechanism, as it has various issues explained in the linked RFC.
I have added this to the section.
> As for deprecating the `E_USER_ERROR` constant, this will lead to a lot of
> guard code
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Tuesday, 2 July 2024 at 07:49, Marc Bennewitz wrote: > Hi Gina, > > On 25.06.24 16:36, Gina P. Banyard wrote: > >> Hello internals, >> >> It is this time of year again where we proposed a list of deprecations to >> add in PHP 8.4: >> https://wiki.php.net/rfc/deprecations_php_8_4 >> As a reminder, this list has been compiled over the course of the past year >> by various different people. >> >> And as usual, each deprecation will be voted in isolation. >> >> We still have a bit of time buffer, so if anyone else has any suggestions, >> they are free to add them to the RFC. >> >> Some should be non-controversial, others a bit more. >> If such, they might warrant their own dedicated RFC, or be dropped from the >> proposal altogether. > > I would like to propose a deprecation of implicit cast to int of numeric > strings using bit shift operators. > > For the following reasons: > 1. In PHP strings are byte arrays and without context it's not possible to > know if "123" is actually a number or just three bytes of 0x313234 > 2. The other bitwise operators `|`, `&`, `~`, `^` already take it as byte > array, only the bit shift operators try to be smart here > 3. Non numeric strings already fail with "Unsupported operand types: string > >> int" > 4. This makes working with byte arrays unnecessary hard and forces you to use > limited and system depending int's. > > https://3v4l.org/IBUDD > > While processing strings as byte arrays using bit shift operators needs a > separate RFC, I think, if there is an agreement on deprecating this implicit > cast it would already be beneficial to have this sooner than later. > > What do you think? I personally think the scope of this is too large as you have not accounted of all the details. If you try to do a bitwise operator between a numeric string and an integer the numeric string will be implicitly converted to an int. However, if you try to use a bitwise operator between an integer and a non-numeric string you also get a TypeError about unsupported operand types: https://3v4l.org/W582TN Thus the current bit shift operators follow from the existing semantics, and curtailling them without doing it for the other bitwise operators doesn't make a lot of sense to me. Moreover, I feel it makes more sense creating dedicated functions for byte array/string bitwise operators and deprecate using the native operators for this and relegate them just for integers. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Saturday, 29 June 2024 at 22:23, mickmackusa wrote:
>> If one can easily use a function incorrectly in a way that is not
>> *immediately* apparent, then I consider the function to be badly
>> designed.
>
> Does that philosophy also cover preg_quote()? I've lost count of the number
> of times that I've seen it used in Stack Overflow answers without a second
> parameter (including array_map('preg_quote', $array)) and its returned value
> used in a regex that has foward slashes as delimiters.
>
> Additionally, it is an unintuitively named function; it doesn't actually
> "quote" anything -- it \e\s\c\a\p\e\s characters. This makes life
> unnecessarily harder for devs who are new to PHP who need to find the regex
> escaping function.
>
> Would it be reasonable to create `preg_escape()` which also (sometimes
> unnecessrily) includes the (de facto default delimiter) forward slash in its
> default list of escaped characters so that preg_quote() could eventually be
> deprecated? As far as I know this would do no harm, will prevent holes in
> code, and make PHP more intuitive.
It would possibly be reasonable, but this is a seperate discussion to this.
Arguably a lot of functions/methods named "quote" do escaping, so this feels
like a more general problem than just ext/pcre.
Moreover, I really don't think people use a forward slash as a defacto default
delimiter, I have always use # as this is what the first tutorial about regexes
that I read used.
Best regards,
Gina P. Banyard
>
Re: [PHP-DEV] [RFC] Operator Overrides -- Lite Edition
On Friday, 28 June 2024 at 18:46, Rob Landers wrote: > Hello internals, > > I'd like to introduce a new RFC: > https://wiki.php.net/rfc/operator_overrides_lite which extends the GMP > extension to support a limited set of operator overriding to developers. It's > designed to be limited and relatively simple, while still being quite > powerful. It would only be available if you have the GMP extension installed > and enabled, but would allow for creating powerful unit libraries (such as > representing money, duration, etc) The design of this RFC is non-sensical. If you want to do operator overloading via an extension, then create a dedicated extension instead of piggy-backing on an already existing extension, this makes even less sense considering the extension is not always available. You wouldn't even need an RFC as you could just write an extension and publish it on PECL and see if people adopt it. As such I will be voting no on this proposal. Sincerely, Gina P. Banyard
[PHP-DEV] [RFC] Make the GMP class final
Hello internals, I would like to present an RFC to make the GMP class final: https://wiki.php.net/rfc/gmp-final This is short and to the point, and I intend to open voting for this after the mandatory discussion period of 2 weeks has happened, i.e. on the 13th of July 2024. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Thursday, 27 June 2024 at 11:22, Kamil Tekiela wrote: > > Yes, that is a better description. I have updated this section of the RFC. Best regards, Gina P. Banyard
Re: [PHP-DEV] [Discussion] Follow-up RFC for BCMath\Number object
On Tuesday, 25 June 2024 at 17:58, Saki Takamachi wrote: > Hi! > > This is a reminder as the feature freeze is approaching. I would like to > restate my current opinion. Apologies for the delay, to much traffic on the list so I forgot to address this. > > > - Suggestions for using 64-bit integer types internally for performance > > > This is probably unnecessary. It's already fast enough, so it might be a good > idea to consider it when we need even more speed. Also, if we want to speed > things up even more, it would probably be better to change the design of the > bc_num structure. ACK, this seems to be fine. > > > - Points out regarding naming, such as changing "powmod" to “powMod” > > > A function called "divmod" is also commonly used in other languages. If > follow that naming, "powmod" is not unnatural. Since "bcpowmod" already > exists, I feel that it is okay to leave it as "powmod”. > > > - Points out regarding comparison methods > > > For now, all comparisons are possible with just "compare", so I'll use only > one comparison method. This requires an override RFC. I'm grouping those points together. My main concern with adding those methods to the class is that this will potentially conflict with any implementation of operator and/or comparison overloading. This is why I would rather not have the methods at all, if the idea is to have a "procedural" API I feel revisiting Andrea's old "Operator functions" RFC would be better. https://wiki.php.net/rfc/operator_functions > > > - Whether existing BCMath functions should accept BCMath\Number > > > At least not in 8.4. I don't think any ideas for how to use scale properly > will be finalized before the feature freezes. ACK, the context is also different than for ext/gmp which I misremembered. > > > - About the behavior when casting BCMath\Number to bool > > > If the value is 0, it is treated as false, otherwise it is treated as true. > This alone may not require an RFC, but I'm planning to create an RFC for the > comparison method, so I'll include it there. I think this is the most sensible, in which case I think GMP should also follow suit and have the same semantics instead of currently being broken when you try to cast to bool. > > > - Regarding whether the method you plan to publish is really necessary > > I decide to delete the format method. We can cast or get the value from the > property. In some cases, we may consider adding it again, but at least not in > 8.4. This also requires an RFC. > Seems sensible to me. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC][Discussion] Enhance JSON error messages
On Wednesday, 26 June 2024 at 15:11, juan carlos morales wrote: > I also think it would be very useful to have better error messages. > > At the moment, we get things like "Syntax Error" ... period, no clue > where the JSON is corrupt or anything else. With big JSONs is very > cumberstone to get to the line and character position where the JSON > is corrupt for example. > > I am already working in a change that would improve error messages > while working with JSONs. > > What I am very close to achieve is to have error messages like "Syntax > Error - at character position X near content Y" something like > that. > > I already know that I can do it, actually there is a Work In Progress > Pull Request for this : > > https://github.com/php/php-src/pull/14672 > > > I repeat, is work in progress. BUT it can be done. Maybe my approach > is not the best ... but one way or another it can be done. > > Please let me know your ideas, thoughts about this. > > Please, dont kill me for the actual code, is WIP. > > Thanks in advance to everyone. > > Juan Hello Juan, I'm in favour of this, but also I do not think this needs an RFC. This is just an enhancement to our current crappy parsing errors, and an RFC feels very much overkill for this. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Tuesday, 25 June 2024 at 23:29, Bruce Weirdan wrote:
> Is there a reason to keep crc32?
Good question, I had a chat with Tim as I thought it was similar to the
md5()/sha1() functions.
Moreover, the crc32() function returns an int, whereas the equivalent of the
hash extension
returns a string, so to get the same behaviour one needs to do:
hexdec(hash('crc32b', $str));
It might still make sense to add it to the RFC, but it would need to be its own
section with
its own rationale.
Best regards,
Gina P. Banyard
>
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Wednesday, 26 June 2024 at 14:54, Kamil Tekiela wrote: > I think the "Deprecate passing E_USER_ERROR to trigger_error()" should > be better explained. Why is using this constant a problem? There is a > link to another RFC, but I can't see an explanation as to why > E_USER_ERROR suffers the same problem as fatal errors do. From an > average Joe's perspective, it looks fine and does the job > https://3v4l.org/e97TO Returning control after an E_USER_ERROR seems problematic to me in the first place, as the condition which lead to the trigger surely implies the current code is unable to handle the situation. See: https://3v4l.org/7pdvO But the issues with fatal errors are the same as explained in the linked RFC, in that destructors (and finally blocks, etc.) are not called. See: https://3v4l.org/J5NXF Using exceptions instead is more robust. Is this explanation clear enough? If so, I will incorporate it into the RFC. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Wednesday, 26 June 2024 at 20:19, Morgan wrote: > I do not believe it is appropriate to deprecate strtok() without a proper > replacement. > > While I agree that its signature is undesirable, the suggested replacement > functions or “just write a parser” are not very pleasant solutions to fill > the void it would leave. > > The stateful functionality it exhibits is incredibly useful, though I will > admit confusing. Would it not be better to change how the functionality is > accessed to reflect the fact that state is preserved rather than remove it > entirely and force a performance burden on developers? First of all, please do not top post on the mailing list. Secondly, please explain how you would provide the statefullness. Thirdly please provide an example of usage of strtok() where the suggestions I have given as replies in this thread are not applicable. If the problem is indeed parsing some very complicated structure and you are using strtok for this, I would argue writing a proper parser is overall better. Of note, I'm not the direct author of this section, I just cleaned it up because the initial wording was... draft state like. Best regards, Gina P. Banyard
Re: [PHP-DEV] Overriding GMP objects
On Wednesday, 26 June 2024 at 18:24, Rob Landers wrote: > Hello internals, > > I've had this little library for a while > (https://github.com/withinboredom/time), mostly as a place to experiment with > the quirks of PHP and take it in weird places. Anyway, I've been > experimenting with "strongly typed time" in attributes for a while now. At > this point, it's a little weird but doable to use something like this: > > #[MyAttribute(units: StandardSecond, amount: 5)] > > ... which is less than ideal. What I would really like is this: > > #[MyAttribute(5 * StandardSecond)] > > PHP doesn't support operator overloading, which, from the last RFC attempt, > probably won't for quite a long time. Thus, I started experimenting with > extending the \GMP class, which is perfectly allowed since it isn't final. > For those that don't know, GMP implements operator overloading such that a > GMP number times an int results in a new GMP number. > > Surprisingly, I can get this to work, but I end up with a GMP number -- with > the right value -- but not the right type. Hence this email. In essence, I am > attempting to "back-door" my way into having operator overloading. > > I would like to add static protected methods to the GMP class that are called > for operations. In the event all objects are base-GMP objects, no behavior > will change. No, GMP not being final was a mistake, mainly due to it the first conversion from resources to opaque objects. I was intending on making the class final via an RFC because no one extends it, as it is pointless (checked also on private codebases via Exakat). AND This whole back-door idea was explicitly shut down in the BCNumber RFC that got accepted for 8.4. I do not want a random extension being abused for this purpose. If you want to add operator overloading by that way you can do something very simple, which is create a new extension which has a class with all the relevant method that overloads the do_operator to call the relevant methods on the class. You've got your back-door without poluting the problem space of an unrelated extension which is not even required to be installed. > - should we revisit operator overloading instead of me hacking my way into it? Yes. > - should we revisit "constant expressions" in attributes I do not see how this relates to the problem space if we have the above or you use a new dedicated extension for this. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Wednesday, 26 June 2024 at 06:39, Dusk wrote: > On Jun 25, 2024, at 22:18, Mike Schinkel m...@newclarity.net wrote: > > > This leads me to think `strtok()` should not be deprecated given how > > inefficient string handling in PHP can otherwise be, at least not without a > > much more efficient object for string parsing. > > > What would be really useful as a replacement for strtok() - among other > things - would be a function analogous to MySQL's SUBSTRING_INDEX(): > > https://dev.mysql.com/doc/refman/8.4/en/string-functions.html#function_substring-index > > Where SUBSTRING_INDEX($a, $b, $c) is functionally equivalent to explode($a, > $b)[$c], but with the added ability to use negative indices to count from the > end of the input. That is a rather interesting function that I did not know existed in MySQL. I agree this would be useful, and probably should be its own RFC/thread. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Wednesday, 26 June 2024 at 06:18, Mike Schinkel wrote:
>> https://3v4l.org/RDYFs#v8.3.8
>
> Note those seven use-cases are found in around the first 25 results when
> searching GitHub for "strtok(". I could probably find more if I kept looking:
>
>> https://github.com/search?q=strtok%28+language%3APHP+=code
>
>>
>
> Regarding explode($delimiter, $str)[0] — unless it is to be special-cased
> during compilation —it is a really inefficient way to find the substring up
> to the first character, especially for large strings and/or when in a tight
> loop where the explode is contained in a called function
Then use a regex: https://3v4l.org/SGWL5
Or a combination of strpos and substr.
I'd bet that both of these solutions would use less memory, and I would guess
the PCRE one should also be better for performance (although not benchmarked)
as it is highly specialized in that task.
There are *plenty* of solutions to the specific problem you pose here, and thus
many different solutions more or less appropriate.
Best regards,
Gina P. Banyard
>
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
On Tuesday, 25 June 2024 at 19:06, Mike Schinkel wrote:
> strtok()
> =
> strtok() is found 35k times in GitHub:
>
>> https://github.com/search?q=md5%28+language%3APHP+=code
>
> It is a commonly used as a "left part of string up to a character" in
> addition to its intended use for tokenizing.
>
> I would prefer not deprecated because of BC breakage, but IF it is deprecated
> I would suggest adding a one-for-one replacement function for the "left part
> of string up to a character" use-case; maybe `str_left("abc.txt",".")`
> returning `"abc"`.
For this exact case of extracting a file name without an extension, you should
really just use:
pathinfo
(
$filepath
, PATHINFO_FILENAME);
But for something more generic, you can just do:
explode($delimiter, $str)[0];
So I really don't see why we would need an "str_left()" function.
Best regards,
Gina P. Banyard
Re: [PHP-DEV] [RFC] Lazy Objects
On Tuesday, 4 June 2024 at 13:28, Nicolas Grekas wrote: > Dear all, > > Arnaud and I are pleased to share with you the RFC we've been shaping for > over a year to add native support for lazy objects to PHP. > > Please find all the details here: > https://wiki.php.net/rfc/lazy-objects > > We look forward to your thoughts and feedback. > > Cheers, > Nicolas and Arnaud Hello, I don't have any strong opinions about the feature in general, mainly because I don't understand the problem space. However, I have some remarks. The fact that an initialize() method has a $skipInitializer parameter doesn't make a lot of sense to me. Because at a glance, I don't see how passing true to it, and not calling the method is different? This should probably be split into two distinct methods. Does get_mangled_object_vars() trigger initialization or not? This should behave like an (array) cast (and should be favoured instead of an array cast as it was introduced for that purpose). How does a lazy object look like when it has been dumped? > The initializer must return null or no value *Technically* all functions in PHP return a value, which by default is null, so this is somewhat redundant. Also, would this throw a TypeError if a value other than null is returned? Best regards, Gina P. Banyard
[PHP-DEV] [RFC] Deprecations for PHP 8.4
Hello internals, It is this time of year again where we proposed a list of deprecations to add in PHP 8.4: https://wiki.php.net/rfc/deprecations_php_8_4 As a reminder, this list has been compiled over the course of the past year by various different people. And as usual, each deprecation will be voted in isolation. We still have a bit of time buffer, so if anyone else has any suggestions, they are free to add them to the RFC. Some should be non-controversial, others a bit more. If such, they might warrant their own dedicated RFC, or be dropped from the proposal altogether. Best regards, Gina P. Banyard
Re: [PHP-DEV] [Early Feedback] Pattern matching
On Friday, 21 June 2024 at 23:58, Robert Landers wrote: > As a user of PHP, this statement concerns me. I don't want any > features rushed just because someone wants it "now" and thus end up > with something feeling half-baked, missing important features or not > completely thought through. I think it's pretty fair that this is a > pretty big RFC (as in scope). Were it a PR under review, I might would > ask you to break it up into smaller PRs because it's too big to > discuss properly and were it smaller PR's we would probably arrive at > a better solution than the giant PR. > > Perhaps, it might be worth breaking up into sub-RFC's (is that a > thing?) where each pattern/feature can be discussed independently and > the vote is whether or not it gets implemented in the parent RFC but > has no binding on the parent RFC. Some things may be easy to discuss > (such as type matching) but others might be longer (such as as, or > arrays). But (and this is the key part) it wouldn't stop you from > proceeding on the parent RFC, which is implementing pattern matching > (in general) and any passed sub-RFC's. > > Maybe that could be a path forward? I don't know who makes the rules, > but they're human rules and they can be anything -- in theory. Maybe > "sub-RFC's" needs an RFC to define it, but that might let you move > faster than a) trying to do everything all-at-once, and b) let > hard-to-define parts of the overall feature get the time they deserve. Breaking up an RFC into sub-RFCs which are each interdependent for the greater scope to be coherent doesn't make any sense. An RFC being "large" is not an issue. Moreover, this RFC is *already* a "sub-RFC" of the much larger in scope meta ADT RFC. The scope of this RFC seems pretty moderate to me and well appropriate, and part of this discussion is to establish what may be moved to later. It is always possible to break down an RFC into new tiny RFCs about every single possible design decision, it doesn't mean this should be done. Writing RFCs, discussing them, and responding to feedback is extremely exhausting and time-consuming, as such the authors of an RFC are entitled to decide what is in scope and what is not. They also decide what can be moved out, and what cannot. Part of being an RFC author is to *also* stand your ground on the scope and design of your RFC while taking into account the feedback. Best regards, Gina P. Banyard
Re: [PHP-DEV] [Early Feedback] Pattern matching
On Friday, 21 June 2024 at 19:19, Larry Garfield wrote: > On Fri, Jun 21, 2024, at 3:35 PM, Brandon Jackson wrote: > > 4. Object matching > > Absolutely a separate rfc please. Definitely needs discussion. Could > > intersect another potentially preferred solution like type aliases. > > Sending one or the other into anti-pattern world. > > Maybe a solution similar to this would be preferred: > > > > `php type MyType = Foo $foo = $bar as MyType|string` > > > As noted, this is on the ADT hot path so postponing it is problematic. > Especially holding it on type aliases, which have been discussed for longer > than this RFC has been around (nearly 4 years) and yet no actual proposal has > ever been put forward. It's unwise to wait for such a feature, especially > when most likely implementations would dovetail well with patterns anyway. I agree with Larry here, this is core to pattern matching in general and necessary for ADTs to make any sense (and I want them yesterday). Moreover, I cannot see how this will conflict with anything vaguely close to type aliases. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum
On Wednesday, 19 June 2024 at 20:14, Claude Pache wrote: > Hi, > > Naming is hard, for sure. Here is my review. I find the names mostly > reasonable, except Round::PositiveInfinity and Round::NegativeInfinity. I > will discuss Round::PositiveInfinity. > > First: > > > I've discussed this with Saki. In that case the `HalfEven` and `HalfOdd` > > modes would also need to be renamed to `HalfTowardsEven` and > > `HalfTowardsOdd` > > > For me, the implied preposition in `HalfEven` is “to”, not “towards”. In > other words, in the HalfEven mode, a half-number is replaced with the nearest > even integer; it is not replaced with a integer in the direction of (or: > towards) an even integer. So, `Round::HalfEven` is fine; but > `Round::PositiveInfinity` does not make much sense to me, as the number is > not rounded to +∞, but towards +∞. > I agree with this part. > --- > > Second, “TowardsPositiveInfinity” is just a mouthful synonym for “Up”. You > could just name it: > > Round::Up > > At this point, you may invoke either Hamming or Levenshtein and compare it > negatively with `Round::HalfUp`. Yes there is a risk a confusion (and I do > think that such a name is suboptimal for this reason), but the confusion is > not just caused by the short Levenshtein distance. That brings to the most > important part of my review. I disagree there, the main motivation of the RFC is to fix the naming of PHP_ROUND_HALF_UP because it does *not* match the mathematical behaviour of rounding half toward positive infinity. And considering multiple other programming languages *also* have made that mistake I do not think that “TowardsPositiveInfinity” is a synonym for "Up". Moreover, I'm not sure something being a mouthful is a good reason to name it something else. > > --- > > In my opinion, the most important criterion for a good name is: > > The name must be clear for itself, not just when comparing it with other ones. > > The problem with `Round::Up` (or `Round::[Towards]PositiveInfinity`), when > you first encounter it, is that it is relatively easy to mistakingly assume > that it is a “half-*” mode, and to erroneously interpret it as > `Round::HalfUp` (or, its synonym `Round::HalfTowardsPositiveInfinity`). > > But that the converse is false: it is impossible to interpret `Round::HalfUp` > as if it were `Round::Up` (or `Round::TowardsPositiveInfinity`), because of > the distinctive “Half” token that immediately indicate the right > interpretation. > > So, the best way to disambiguate `Round::Up` from `Round::HalfUp`, is not to > replace “Up” with some creative synonym, but to add a distinctive token that > plays the role of — and contrasts with — “Half”. I don’t know if the > following suggestion makes sense for you, but it is the one I have found: > > Round::FullUp > This is an interesting point of view, but what this tell me is not an issue with Up or Down on its own, but that seemingly for you and others the focus of rounding is how to break ties, not about the rounding itself. Moreover, and this is the part where I think the naming of “TowardsPositiveInfinity” is better, is because you said yourself that: > the implied preposition in `HalfEven` is “to”, not “towards” Which, at least to me, also implies that if you see something that includes "Towards" you stop thinking about the tie breaking behaviour and thus just think about the total/complete rounding behaviour. > - > > That said, I think that there is an even better option. I know you will not > like it, but bear with me. I sincerely think that the best name is just: > > Round::Ceiling > > It is short, distinctive, and standard across the computing industry. > > Yes, this name is idiosyncratic to English and not used in several other > (natural) languages, and if you don’t know English, you will not grasp the > metaphor and have to just learn it. However, whatever other name you invent, > you have to learn “ceil” anyway, because you will encounter it sooner or > later. Many common (programming) languages, including JavaScript, C++, Java, > Python, have a `ceil` function. Even if you manage not to learn any of those > and to code in PHP only, you are at risk to stumble on its built-in > `ceil(...)` function, or its newly-introduced `bcceil(...)` variant. > > Therefore, unless we find a name that is really good, I suggest to not fall > into the NIH syndrome, and not to force users to learn another name in > addition to “ceiling”. > I don't see how this falls into the NIH syndrome, because it has not been invented here. The terminology chosen is standard in mathematics, and even more so in mathematical speech in other languages. Best regards, Gina P. Banyard
Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"
On Tuesday, 18 June 2024 at 17:37, Robert Landers wrote: > Hello internals, > > [...] > > What are your thoughts? As self-proclaimed leading expert on PHP type juggling. That it is a terrible idea with no gains whatsoever. Renaming the declare statement does not improve the situation. > PS. Personally, I would rather unify non-strict and strict in some way > that makes sense ... so, that route sounds nice too. See my old meta RFC: https://github.com/Girgias/unify-typing-modes-rfc It is a somewhat known hot take from mine that I think the strict_type declare statement was a mistake. [1] Mainly because it affects barely nothing in regard to the engine. I have written/co-authored multiple RFCs over the years to make the default coercion mode less whack. [2][3][4][5][6][7] And my container/offset RFC is in the same vein [8] which lead me into a different rabbit hole then the one I was expecting to explore which is addressing PHP's weird comparison semantics. [9] Therefore, I would rather we focus on *actually* fixing PHP's semantics, than arguing about changing the name of something that shouldn't really exist in the first place. Best regards, Gina P. Banyard [1] Slide 68 of my PHP UK talk "PHP's Type System Dissected": https://gpb.moe/doc/slides/PHP_Type_System_Talk_PHPUK2023.pdf [2] https://wiki.php.net/rfc/saner-numeric-strings [3] https://wiki.php.net/rfc/implicit-float-int-deprecate [4] https://wiki.php.net/rfc/saner-inc-dec-operators [5] https://wiki.php.net/rfc/locale_independent_float_to_string [6] https://wiki.php.net/rfc/exit-as-function [7] https://wiki.php.net/rfc/deprecate-boolean-string-coercion [8] https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md [9] https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md
Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum
On Tuesday, 11 June 2024 at 20:47, Tim Düsterhus wrote: > Hi > > Am 2024-06-08 02:29, schrieb Saki Takamachi: > > > Regarding 1, personally, I support Gina's opinion of only providing > > the new rounding modes as an Enum. > > This can be interpreted as changing the rounding mode to Enum, with > > the existing constants being kept simply for backward compatibility. > > > I've talked about this with Saki in private. We both agree that > providing the 4 new rounding modes only by means of the proposed > `RoundingMode` enum is the right choice. I have made the necessary > adjustments to the RFC text. There is a new "Rounding Modes introduced > in PHP 8.4" section that explains that the 4 constants will be removed > as part of the `RoundingMode` enum RFC. > > Best regards > Tim Düsterhus Thank you, I think other than possibly prefixing the NegativeInfinity and PositiveInfinity cases with "Towards" I am happy with the content of the RFC. Best regards, Gina P. Banyard
Re: [PHP-DEV] Property hooks, and write behavior
On Wednesday, 12 June 2024 at 16:06, Ilija Tovilo wrote: > Hi everyone > > [...] > > I hope that these semantics are acceptable for everyone. > > Ilija Hello Ilija, I might know what sort of technical issues you've been running into, as I have some similar issues correctly handling references with my Container/Offset RFC implementation. The way I'm handling this is by splitting the "get"/read handler/hook to *just* be a by-value return, and for fetching creating a new "fetch" handler that is called in the respective situations. Therefore, I am wondering if it wouldn't possibly make more sense to add a "fetch" hook, and ban returning by-ref for the get hook. Best regards, Gina P. Banyard
Re: [PHP-DEV] Revisiting case-sensitivity in PHP
On Tuesday, 11 June 2024 at 15:38, Valentin Udaltsov wrote: > Hi, Ben and Levi! Thank you for your interest! > > Could you, please, elaborate on why you propose to target 9.0? That would > make perfect sense if PHP strictly followed semver, but we always have some > BC breaks in minor releases > (https://www.php.net/manual/en/migration82.incompatible.php, > https://www.php.net/manual/en/migration83.incompatible.php). So, is there a > real difference between 8.4 and 9.0 for this case? Or do you mean that this > BC break is way too big for 8.4? > > Levi, if we bundle namespaces, classes and functions in a single change, will > that be easier to implement? Basically to remove lowercasing and put the > original type names in the lookup tables? While we do make backwards incompatible breaks in minor PHP version (and we have done since the beginning of time, I checked last time this argument came up) we do keep them to a minimum and to be "small" BC breaks, the judgement of what "small" means is fuzzy. Plenty of us thought converting resources to opaque object was "small" but others disagreed. And I agree with Levi here, I am in favour of this change, but I don't think it should land in a minor. For PHP the namespace is just a prefix to any symbol to be able to distinguish them, and namespaces are already canonicalized to be lowercase, this has been an issue when trying to remove the memory footprint of constants, as the casing of namespace was lost. [1][2][3] Indeed you can access a namespace constant with two different casing in the namespace. [4] One difficulty is that checking the casing at runtime for all classes/functions to check if they are conformant would likely lead to a big performance degradation. It _might_ be possible to check some of these things at compile time (well at least for functions) if the class/function is already available in the symbol table. Best regards, Gina P. Banyard [1] https://github.com/php/php-src/pull/10954 [2] https://github.com/php/php-src/issues/11423 [3] https://github.com/php/php-src/pull/11604 [4] https://3v4l.org/ju4F0 >
Re: [PHP-DEV] Re: [RFC] [Under Discussion] New ext-dom features in PHP 8.4
On Wednesday, 5 June 2024 at 17:19, Niels Dossche wrote: > > Hi internals > > It's been two weeks since I announced the RFC, and it's been very calm so far. > That either means everyone agrees or no one cares, let's assume it's the > first one ;). > If nothing comes up, I'm going to put it to vote Monday (i.e. June 10th). > > Kind regards > Niels I am in the agree camp, looking forward to the vote as those are sensible additions. Best regards, Gina P. Banyard
Re: [PHP-DEV] Introduction
On Tuesday, 4 June 2024 at 12:57, Bilal Gültekin wrote: > Hello, > > I'm Bilal Gultekin (wiki username: bilal). I have almost 20 years of PHP > experience. I'd like to follow up on proposed RFCs, comment on them, and > maybe create one myself. > > I'm from Istanbul, Turkey. You can check out my GitHub > (https://github.com/bgultekin) and LinkedIn > (https://www.linkedin.com/in/bilalgultekin/) profiles. > > Thanks! > -- > > Bilal Gültekin Hello Bilal, Thank you for your interest! As Tim said, you can comment on RFCs by just replying to the relevant email thread. Be aware that we have some rules to participate on the mailing list listed on GitHub: https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md The main one is to *not* top post (which most email clients seem to do by default annoyingly enough). Unless you already have an RFC in mind, and possibly a draft (can be a gist, github repo, whatever) we don't generally grant Wiki editing rights. Feel free to ask any more questions! Best regards, Gina P. Banyard
[PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum
On Sunday, 2 June 2024 at 22:26, Jorg Sowa wrote: >> by *removing* the newly introduced constant and instead exposing the >> functionality *only* via the new Enum. > It brings inconsistency that some modes are accessible by ints and enums and > others only by enums. If there is no deprecation plan yet I am not sure this > is the right approach. We cannot formally deprecate the constants in the same version as introducing the enums as there would be no transition period. We can however soft deprecate the usage of the constants in the documentation by recommending to use the enumeration instead. However, I don't see _any_ point in having both constants and enum cases for the new modes as there is no incentive what so ever to use the enum. It is *by design* to have an inconsistency, you want the new feature, use the new and better way. Let's imagine we do introduce those new constants alongside the enum, from a user PoV there is no clear reason why one should use constants above enums or enums above constants, except if you care about type safety. Now, let's fast forward in this imaginary world and we decide to formally deprecate the constants and tell people to use the enum. For every single user that decided to use the constants, especially for the new rounding modes, they now need to go and fix their code because we didn't clearly incentivise people to use, what I deem, to be the recommended way forward. Moreover, this equivalence will be an argument _against_ deprecating the constants. And finally, if we decide to add actual support for half up/down rounding, there is no way to establish an equivalence with a sanely named constant because the name is already taken for an incorrect mode. So once again, if this RFC does not remove the constants for the new rounding mode I see less of a point, because it is "just" improving the naming (which is really needs considering how bonkers wrong it currently is). This RFC *must* be passed for 8.4 to ammend your RFC, because I frankly don't want to be doing clean-up on yet another bad decision the project did that will haunt us for decades if the current state gets released. Best regards, Gina P. Banyard >
Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum
On Friday, 31 May 2024 at 15:49, Saki Takamachi wrote: > Hi, internals! > > I would like to start an RFC discussion regarding rounding modes. > https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum > > As mentioned previously by Gina on the mailing list [1], there are some > issues with PHP's current rounding mode. > [1] - https://externals.io/message/123126 > > • First, the value is just an int, so we need to verify that the value passed > is a valid rounding mode. > • The second problem is that the behavior of the “up” and “down” modes does > not match the mathematical definition. Especially for non-native speakers, > the different rounding modes might also be more easily confused, compared to > a naming that uses less abstract terms. > > To resolve these issues, change the naming to something appropriate and use > Enums instead of int constants. > > Please see the RFC for details. > > Regards, > > Saki IMHO, part of the RFC should be to amend the "Add 4 new rounding modes to round() function" RFC [1] by *removing* the newly introduced constant and instead exposing the functionality *only* via the new Enum. Especially as those constant have not yet been in a stable release of PHP. Other than that, and seeing the confusing of some other people, maybe using the names "TowardsPositiveInfinity" and "TowardsNegativeInfinity" is better. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum
On Friday, 31 May 2024 at 18:15, Larry Garfield wrote: > On Fri, May 31, 2024, at 4:41 PM, Jorg Sowa wrote: > > > Hey Saki, > > I like this change. When I was implementing additional rounding modes > > for the next PHP version I was initially struggling with the naming and > > this change will be helpful. > > > > I have only one concern about the names `NegativeInfinity` and > > `PositiveInfinity`. They may be too formal from the user's perspective. > > As we already have functions `ceil` and `floor` it's more intuitive for > > developers to understand the logic of ceiling and floor rounding. > > > > But if voters will prefer those terms then it makes sense to change the > > constants implemented in PHP 8.4 (and thus not released yet) from > > `PHP_ROUND_(CEILING|FLOOR)` to > > `PHP_ROUND_(POSITIVE_INFINITY|NEGATIVE_INFINITY)` for the sake of > > consistency. > > > > Kind regards, > > Jorg > > > I was confused by those as well. It's not obvious to me what those even do. > Do they mean "away from 0"? If not, then I have no clue what they are. :-) > > --Larry Garfield Considering that there are already "Away from 0" and "Towards 0" enum cases, the Towards Positive Infinity/Towards Negative Infinity cases "obviously" don't mean this. Towards positive infinity means that for positive numbers you round to the integer part plus 1, and for negative numbers you "just" take the negative integer part. Similarly, for rounding towards negative infinity positive numbers round to "just" the integer part of it, and negative numbers round to the negative integer part minus 1. It should also be noted that ceil/floor is very English specific terminology that may not be immediately obvious to non-English speakers, thus my preference for using some variation of towards positive/negative infinity. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
On Tuesday, 28 May 2024 at 15:26, Derick Rethans wrote: > On Mon, 27 May 2024, Ilija Tovilo wrote: > > > On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard intern...@gpb.moe > > wrote: > > > > > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard > > > intern...@gpb.moe wrote: > > > > > > > I would like to formally propose my idea for exit() as a function > > > > brought up to the list on 2024-02-24 [1] with the following RFC: > > > > https://wiki.php.net/rfc/exit-as-function > > > > > > As there haven't been any comments for nearly two weeks, I'm > > > planning on opening the vote for the RFC on Tuesday. > > > Right now, I am not going to be in favour of this. Specfically because > the Backward Incompatible Changes don't list some of the backward > breaking changes, and no mitigations are provided. See below. > > I also don't see the benefit from doing this in the first place. > exit/die has always meant "bail straight out", without any function > semantics (from https://www.php.net/exit): > > exit — Output a message and terminate the current script > > exit is a language construct and it can be called without > parentheses if no status is passed. > > It's not that this a particularly new or novel behaviour. > > I saw somewhere else in the thread that the exit construct could already > throw a catchable exception. I consider that a bug. Considering the whole point of the RFC is to make it a function, I'm not sure why saying the current exit behaviour is not new or novel serves any purpose. Is catching a TypeError a bug? Is catching a ValueError a bug? Is catching any sort of engine Error a bug? Because this is effectively what you are saying, and if this is the case, we might as well just reverse the "Exceptions in the engine" RFC from 2014 [1] to make all those Errors fatal errors again which bail out immediately. This RFC makes exit() a function such that either it exits normally, or a TypeError is thrown if you feed it nonsense, consistently with all our type juggling semantics. Moreover, when exit() was changed to use an Exception internally there were various people in favour of being able to catch it, and have it run finally blocks (like other programming languages do) [2] It should also be noted exit() does not just bail out and do nothing else, any destructors will be run before the exiting, so one can still run userland code after it has been called [3] > I have just checked this for Xdebug, and you're definitely right with > that. With the removal of the ZEND_EXIT opcode, it can not now detect a > scope/function exit now. > > It also breaks my "do tasks on ZEND_EXIT" with the profiler. It is used > to always write the closing profiling footer to the files. Without me > being able to overload thati opcode, data would not be complete. > I even have two bugs (with tests) for this: > > - https://bugs.xdebug.org/68 > - https://bugs.xdebug.org/631 > > Xdebug has been overloading ZEND_EXIT for nearly 20 years now. AFAIK Opcodes are not part of any backwards compatibility guarantees. You could overwrite the function pointer of exit() at MINIT with a custom implementation. Alternatively, you could use the zend_is_unwind_exit() engine API to check if the exception that has been thrown is the one that corresponds to an exit call, this would work as of PHP 8.0. Finally, the one that makes more work for me, is to add a new observer API that indicates an exit() and hook into that one. > > > This could be re-added by checking for the never return type instead. > > > I can't quite see a way on how to do that? The EXIT is replaced by an > INIT_FCALL/DO_ICALL: > > 4 0 E > EXT_STMT > > 1 ECHO '55' > 5 2 EXT_STMT > - 3 > EXIT > > - 6 4* EXT_STMT > - 5* ECHO '675' > - 7 6* EXT_STMT > - 7* > RETURN null > > + 3 INIT_FCALL 'exit' > + 4 DO_ICALL > + 6 5 EXT_STMT > + 6 ECHO '675' > + 7 7 EXT_STMT > + 8 > RETURN null > > > The opcodes don't have direct access to the type mask structure as far > as I know. You can access the zend_function pointer from the opcode which has access to the type-mask info. Or, if required, the Zend/Optimizer/zend_func_infos.h file can be amended to include exit() and die() and expose the MAY_BE_NEVER return type. Best regards, Gina P. Banyard [1] https://wiki.php.net/rfc/engine_exceptions_for_php7 [2] https://externals.io/message/107497 [3] https://3v4l.org/gO9IK
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
On Monday, 27 May 2024 at 02:31, Ilija Tovilo wrote: > Hi Gina > > On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard intern...@gpb.moe wrote: > > > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard intern...@gpb.moe wrote: > > > > > I would like to formally propose my idea for exit() as a function brought > > > up to the list on 2024-02-24 [1] with the following RFC: > > > https://wiki.php.net/rfc/exit-as-function > > > > As there haven't been any comments for nearly two weeks, I'm planning on > > opening the vote for the RFC on Tuesday. > > > As mentioned early on in private, I don't see a convincing reason to > remove tokenizer/parser support for exit/die. I'd rather see this > handled in the parser directly, by converting the standalone keywords > to function calls. This avoids any backwards incompatibility, and > avoids special handling in zend_compile_const. I must be honest, I don't really understand how parsers work, so I went with what I could understand and implement. But I'm struggling to see a reason for keeping the token in the first place, and what issues hooking into zend_compile_const() has. > > Another thing that's probably not too important: The PR likely breaks > dead code elimination for exit() and die(). This could be re-added by > checking for the never return type instead. Checking for a never return type seems more robust if it wasn't already supported by DCE. I will see if I can do this. > You'd also need to > special-case the lookup of exit/die in namespaced code, where it will > always refer to the global function (as they cannot be declared in > userland). This is a pre-existing issue with assert() too then, I am happy to fix this at the same time if the RFC passes. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
On Monday, 27 May 2024 at 19:10, Claude Pache wrote:
> Hi Gina,
>
> It is ok, for `exit` to be wired to a function. However, the paren-less
> `exit` syntax is absolutely reasonable and should be kept in the long term
> (more on this below). It is true that your proposal doesn’t remove the
> paren-less form, but the implementation (a hack around constant evaluation)
> strongly suggests that it is desirable to deprecate it in the future (hey, it
> is even the very first item of the `Future scope` section). Therefore, I
> think it is preferable to keep proper parsing rules for `exit`.
>
> Now here is why I think that `exit` syntax without parentheses is reasonable.
> For me, `exit` is a control-flow instruction, saying to terminate the
> program, just like `return` terminates a function or `break` terminates a
> loop. I don’t care about implementation details, whether it is implemented as
> invoking a never-returning function, or as throwing a hidden exception, or
> whatever. The fact is, in typical use:
>
> `php header("Location: /somewhere/else.php"); exit;`
>
> I would consider an oddity and useless noise to put empty parentheses after a
> bare `exit`, just as I wouldn’t consider to put empty parentheses after a
> bare `return`.
>
> (BTW... I wouldn’t describe a bare `yield` (equivalent to `yield null`) as
> “constant” evaluation, even if it may be found in same positions as a “real”
> constant.)
>
> —Claude
Adding something to Future Scope does not mean I will pursue this, this is just
a possible direction that can be done and needs to be argued on its own merits.
And frankly I have no intension on pushing this, I would _rather_ remove
support for passing strings to exit() than removing the paren-less form.
It should be noted that in other programming languages, exit() is a function
that requires an argument for the status code.
So I don't think of it as a control-flow instruction (because I don't see
terminating something as control flow) but if that's how you see it fine.
If that's the only reason for keeping proper parsing rules, I'm not sure
whether that's worthwhile IMHO.
Best regards,
Gina P. Banyard
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
On Tuesday, 28 May 2024 at 07:53, Daikaras wrote: > > I feel like the reasoning in this RFC is misguided. `exit` behavior is > not consistent with functions because it is not a function. But it is > consistent with constructs like `echo`. Or am I wrong? I'm all for > stricter typing but not at a cost of reliability. `exit` IMO should > always terminate script, no exceptions (no pun intended :)). Otherwise, > it may have security implications in some codebases, as Saki pointed > out. So I'd rather have it error fatally like for example `break` does > when passed non-integers. And on the same note maybe syntax could be > improved to not require parentheses when passing the code (so `exit 0;` would > be valid) since it seems to be the cause of the confusion. > > Just my 2c. > > p.s. In B/C table you should mention that passing Stringable objects > will throw TypeError when `strict_types` are enabled. This is not the cause of my confusion. If you had read the RFC carefully, you would have seen that exit() already throws a TypeError that can be caught if you pass in a non-stringable object. So the argument that it should always exit is invalid. Moreover, in other programming languages exit() is a function, and I don't see a reason for having something be a language construct when there is no need for it. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
On Tuesday, 14 May 2024 at 17:24, Juliette Reinders Folmer wrote: > On 11-5-2024 16:43, Gina P. Banyard wrote: > >> On Thursday, 9 May 2024 at 15:17, Jorg Sowa >> [](mailto:jorg.s...@gmail.com) wrote: >> >>>> I don't think there are any other "functions" like this. >>> What about list(), isset(), print(), echo(), require(), include(), unset(), >>> empty()? We use them the same way as functions, but those are not real >>> functions. >> >> list() (and array()) may look like functions but do not behave like one as >> they affect the current scope by setting various variables. >> >> isset()/empty()/unset() require to work with undefined variables and have >> deeply ingrained behaviour within the engine, so making them simple >> functions is not as much of a "trivial" change. >> >> print, echo, include(_once) and require(_once) do not mandate their >> "argument" to be passed within parenthethis, so making them functions does >> not simplify the lexer/parser nor removes them as keywords. >> Also I don't know the last time I've used those language constructs "like a >> function". > > Seeing this list, makes me wonder: what about eval() ? eval() might make sense to try and convert to a function, this would probably also cleany solve the complaint about not being able to disable eval() [1][2] Best regards, Gina P. Banyard [1] https://bugs.php.net/bug.php?id=62397 [2] https://github.com/php/php-src/pull/4084
Re: [PHP-DEV] [RFC] [Vote] #[\Deprecated] attribute
On Wednesday, 22 May 2024 at 08:22, Benjamin Außenhofer wrote: > The vote for the RFC #[\Deprecated] attribute is now open: > > https://wiki.php.net/rfc/deprecated_attribute > > Voting will close on Wednesday 5th June, 08:00 GMT. I have voted in favour of the RFC, I don't have any strong opinions about the "since" parameter, so I will let other people judge on this matter. However, any discussion about how deprecations are currently being triggered is, IMHO, irrelevant to this discussion. PHP, at this point in time, triggers a deprecation diagnostic via the same mechanism that notices, warnings, etc. diagnostics are triggered. There might be value to separate the deprecation diagnostic mechanism from the other diagnostics to have them be globally toggled on/off and sent logs into a different file than the other diagnostics, but like said by others, this is an orthogonal issue to this one, and one that has long existed in the language. Every other internal attribute that has been added to PHP has some visible effects to the user, having it do nothing seems rather odd to me. Best regards, Gina P. Banyard
Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
On Thursday, 2 May 2024 at 13:48, Ollie Read wrote: > Hi All, > > I've been working on a PR that introduces > ReflectionFunctionAbstract::getParameter() and > ReflectionFunctionAbstract::hasParameter(), to fall more inline with the > other method sets we have, as well as just generally making peoples lives > easier. > > The PR is here: https://github.com/php/php-src/pull/10431 > > These methods accept an integer to retrieve a parameter by its position, or a > string to retrieve by its name. So far, I have built this so that if you > required the first parameter, it's parameter 0. I treat it this way because > the only other place where we deal with parameter indexes, is > ReflectionFunctionAbstract::getParameters() which returns the parameters > zero-indexed. > > The question that is holding this PR back is should these methods be 1 > indexed, so that the provided position is consistent with the error messages, > or how a person would typically count, or should they be 0 indexed to remain > consistent with the existing API. > > Girgias has asked that I pause the PR until we can have a discussion on this > mailing list about how to approach it, so I'm looking for feedback on this I am not sure why I had not thought about checking this earlier, but ReflectionParameter has a getPosition method [1], where the first parameter of a function/method is 0. So the _best_ argument for having it 0 indexed based is to be consistent with the existing semantics. So I am fine with having it 0 indexed. Best regards, Gina P. Banyard [1] https://www.php.net/manual/en/reflectionparameter.getposition.php >
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
On Thursday, 9 May 2024 at 16:18, Saki Takamachi wrote:
> Hi Gina,
>
> > Hello Internals,
> >
> > I would like to formally propose my idea for exit() as a function brought
> > up to the list on 2024-02-24 [1] with the following RFC:
> > https://wiki.php.net/rfc/exit-as-function
> >
> > There have been some slight tweaks to the implementation, namely that the
> > transformation from a "constant" to a function is done at compile time and
> > we do not hook into the behaviour of constants any longer.
> >
> > Let me know what you think.
> >
> > Best regards,
> >
> > Gina P. Banyard
> >
> > [1] https://externals.io/message/122483
>
>
> I generally agree :)
>
> My only concern is that if this function throws an error and I catch it,
> won't it proceed against the user's intentions about it. I am concerned that
> this may lead to data corruption and personal information leaks due to
> unintentional data being inserted into the DB.
>
> `try { exit([]); } catch (Throwable) { // }`
>
> Probably no one likes to write code like this, and even if there are, there
> are probably very few, but code that is written with the assumption that exit
> will always stop processing may be a little dangerous.
>
> Is it nonsense to always stop processing even if an error occurs? Or, how
> about creating an uncatchable exception class specifically for exits? Or is
> this level of risk negligible?
>
> I am writing down the ideas I came up with, so please excuse me if there are
> any mistakes in my understanding.
>
> Regard,
>
> Saki
You can already escape an exit() call, either by setting an error handler that
throws, or by passing a non-stringable object.
See: https://3v4l.org/vR3up
Best regards,
Gina P. Banyard
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
On Thursday, 9 May 2024 at 15:17, Jorg Sowa wrote: >> I don't think there are any other "functions" like this. > What about list(), isset(), print(), echo(), require(), include(), unset(), > empty()? We use them the same way as functions, but those are not real > functions. > Kind regards, > Jorg list() (and array()) may look like functions but do not behave like one as they affect the current scope by setting various variables. isset()/empty()/unset() require to work with undefined variables and have deeply ingrained behaviour within the engine, so making them simple functions is not as much of a "trivial" change. print, echo, include(_once) and require(_once) do not mandate their "argument" to be passed within parenthethis, so making them functions does not simplify the lexer/parser nor removes them as keywords. Also I don't know the last time I've used those language constructs "like a function". Hope this clarifies things. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
On Saturday, 11 May 2024 at 09:05, Juliette Reinders Folmer wrote: > On 8-5-2024 15:40, Gina P. Banyard wrote: > >> I would like to formally propose my idea for exit() as a function brought up >> to the list on 2024-02-24 [1] with the following RFC: >> https://wiki.php.net/rfc/exit-as-function >> There have been some slight tweaks to the implementation, namely that the >> transformation from a "constant" to a function is done at compile time and >> we do not hook into the behaviour of constants any longer. > > No objections from my side, though, yes, PHPCS will need to be > updated/adjusted to work around this, but that's no biggie. > > When reading the RFC, there are two things about which I still have questions. > > 1. As things are, `exit` and `die` cannot be used as a label for a goto > statement. > > ```php > goto exit; > > exit: > echo 'exited'; > ``` > https://3v4l.org/fluuk and https://3v4l.org/cNMEW > > Will that change now `exit` would no longer be a reserved keyword ? I had not thought about goto labels, but indeed it would be possible to use exit and die as goto labels with this RFC. I have clarrified this change in the RFC text and added tests for this in the PR. > 2. The RFC mentions the "old" semantics regarding type juggling for exit/die > - always cast to string - and it mentions that passing resources or arrays in > the new situation will become a TypeError, but that still leaves some room > for interpretation for the other types, in particular the handling of > booleans. > > How I read the RFC, the type juggling would change as follows (but I may well > be wrong!): > > | Param passed | Old | New | Consequences | > |---|-|---|---| > | integer | integer | integer | No change, interpreted as exit code | > | string | string | string | No change, interpreted as status message | > | bool | string | integer | Was status message, now exit code | > | float | string | integer | Was status message, now exit code, "Implicit > conversion from float to int loses precision" deprecation notice | > | null | string | integer | Was status message, now exit code, "Passing null > to parameter #1 ($status) of type string\|int is deprecated" | > | stringable object | string | string | No change, interpreted as status > message | > | non-stringable object | string | TypeError | | > | array | string | TypeError | | > | resource | string | TypeError | | > > Might it be an idea to make all the type juggling changes explicit in the RFC > ? (and correct whatever I interpreted incorrectly) I have done so, and fixed the one case you got wrong. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] [vote] Support object type in BCMath
ing BCMath function going to be adapted to handle the new > > Number object or not? > > > No, that is not considered at this time. I am struggling to see a reason for not considering this. > > > - What is the behaviour when casting a Number object to bool? Does it > > always cast to true like a "standard" object, or does a Number equal to 0 > > cast to false? > > > That's a good topic. I didn't include any mention of this in the RFC because > there was no discussion about it. Personally, I like to return a bool value > that reflects the internal numerical state, like an int. > > However, since I would like to avoid adding such specifications later when > voting has already begun, I will use the same as a "standard object" for now. > If this RFC is passed, I will additionally propose it in another RFC. The lack of discussion about this topic is not a good excuse for not having addressed this in the RFC. This topic should have come up on its own while writing the RFC as this is something that you should have considered, in the same way you have considered how casting to string works. Moreover, RFC discussions are steered by the content of the RFC, and non-mentioned issues requires other people to consider cases that have not been explicitly address, something that is difficult. > > > - Considering the property hook RFC has been accepted, should the $value > > property be a "virtual" property or not? > > > I think that's probably so. But my understanding is that in this case I don't > think it makes any difference to the user. ACK. I feel this RFC has been brought to a vote too early, as such I am changing my vote to no. I am generally in favour of the concept, but there are too many details that are unanswered or didn't even get proper attention for me to feel comfortable with the state of the RFC in question. Best regards, Gina P. Banyard [1] https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md [2] https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md
Re: [PHP-DEV] [RFC] [vote] Support object type in BCMath
On Wednesday, 1 May 2024 at 09:55, Saki Takamachi wrote: > Hi all! > > Voting for RFC: Support object type in BCMath has started. Voting ends on > 2024-05-16 00:00 GMT. > https://wiki.php.net/rfc/support_object_type_in_bcmath > > Regards, > > Saki I voted in favour, as Number being its own type should improve DX and performance for small numbers as we can just store two 64bit integer, one for the integral and another for the fractional part. However, I have some remarks and questions. Apologies if these were already brought up, but I haven't gone through the whole 100 long email thread. - The comparison method should either be called "cmp", or "compare" to align with other extensions, the BC Math function being called bc_comp is weird. - I don't understand why we are exposing lt, lte, gt, and gte what is the rationale here? Also, the naming is kinda terrible IMHO. - The "powmod" method should probably be called "powMod" - Are the existing BCMath function going to be adapted to handle the new Number object or not? - What is the behaviour when casting a Number object to bool? Does it always cast to true like a "standard" object, or does a Number equal to 0 cast to false? - Considering the property hook RFC has been accepted, should the $value property be a "virtual" property or not? Best regards, Gina P. Banyard
Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
On Friday, 3 May 2024 at 16:47, Derick Rethans wrote: > On Fri, 3 May 2024, Gina P. Banyard wrote: > > > On Thursday, 2 May 2024 at 21:33, Derick Rethans der...@php.net wrote: > > > > > On 2 May 2024 13:48:36 BST, Ollie Read php@ollie.codes wrote: > > > > > > > These methods accept an integer to retrieve a parameter by its > > > > position, or a string to retrieve by its name. So far, I have > > > > built this so that if you required the first parameter, it's > > > > parameter 0. I treat it this way because the only other place > > > > where we deal with parameter indexes, is > > > > ReflectionFunctionAbstract::getParameters() which returns the > > > > parameters zero-indexed. > > > > > > > > The question that is holding this PR back is should these methods > > > > be 1 indexed, so that the provided position is consistent with the > > > > error messages, or how a person would typically count, or should > > > > they be 0 indexed to remain consistent with the existing API. > > > > > > 0-indexed, as that's what PHP does everywhere else. > > > > Well not really, if you have an error (TypeError or ValueError) which > > indicate what parameter is the problem, it will be 1-indexed. > > > Which API in PHP is 1-indexed? > > cheers, > Derick I have given the 1-index API which is ob_get_level() in my email reply, so I'm confused by the question here. ob_get_level() starts at 1 for the 1st level and increases from there. If the function returns 0 then output buffering is disabled. However, if you retrieve the full statuses of output handlers via ob_get_status() it returns a 0-index array. So to get the correspondence between the output buffer from ob_get_level() and ob_get_status() you need to do +/- 1 with the indexes/levels. I am just pointing out that such a difference in APIs already exists *within* PHP. Like I said earlier, I don't frankly care *what* the consensus is, but considering it was split *within* the reviewers of the PR it needed to be brought to the attention of internals. I find 0-indexing in this case utterly confusing, but that's possibly just me. And if most people are in favour of 0-indexing, then let it be 0-indexing. Best regards, Gina P. Banyard
Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function
On Thursday, 2 May 2024 at 21:33, Derick Rethans wrote: > On 2 May 2024 13:48:36 BST, Ollie Read php@ollie.codes wrote: > > > These methods accept an integer to retrieve a parameter by its position, or > > a string to retrieve by its name. So far, I have built this so that if you > > required the first parameter, it's parameter 0. I treat it this way because > > the only other place where we deal with parameter indexes, is > > ReflectionFunctionAbstract::getParameters() which returns the parameters > > zero-indexed. > > > > The question that is holding this PR back is should these methods be 1 > > indexed, so that the provided position is consistent with the error > > messages, or how a person would typically count, or should they be 0 > > indexed to remain consistent with the existing API. > > > 0-indexed, as that's what PHP does everywhere else. > > cheers > Derick Well not really, if you have an error (TypeError or ValueError) which indicate what parameter is the problem, it will be 1-indexed. Which, for me, makes it more logical to have it 1-indexed. If the ReflectionFunctionAbstract::getParameters() API did not exist, this is what I would have pushed for. Moreover, PHP already has a 1-indexed and 0-indexed discrepancy with the ob_get_level() and ob_get_status() functions. In the end, I don't really care what we choose, but this just needed clarification from internals on how to proceed. Best regards, Gina P. Banyard
Re: [PHP-DEV] Re: Proposal to Create a MariaDB Alias for the MySQL PDO Driver
On Tuesday, 30 April 2024 at 22:33, Kamil Tekiela wrote: > I see absolutely no reason to do this. There is no difference between > MySQL and MariaDB in terms of PDO. Sure, the actual RDBMSs have > differences, but they play no role when it comes to PDO. > If MariaDB decides to change the protocol some day then we would need > a new driver to replace mysqlnd. Only then it would make sense to have > PDO_mariadb extension. But that is unlikely to happen any time soon. > The purpose of PDO subclasses is to offer driver specific > functionality and differentiate SQL syntax flavours. MariaDB and MySQL > use the same driver so they offer the same functionality and they use > the same SQL syntax (at least the parts that matter). And we must > remember that MariaDB is not the only MySQL-like DB out there. We are > not going to create a name alias for every possible fork of MySQL that > ever exists. It would be pointless. I agree with Kamil, MariaDB wanting to be incompatible with MySQL is their choice. If we introduce an "alias" and the MariaDB behaviour doesn't work, then we are on the hook to "fix" a database driver where we don't have the expertise. The MySQL driver is intended to only be used with a MySQL database, that it works with MariaDB is just a consequence of them forking from MySQL. And a user that uses a driver of a different DB than the one they run should expect incompatibilities. If there is a need for a MariaDB driver, then it should live outside the php-src repo, IMHO. We already have database drivers that are badly maintained because we don't have the expertise, or only recently acquired people that want to work on them. We removed the interbase and OCI8 extensions from php-src to PECL for this exact reason. Thus adding, effectively, a new database driver makes no sense to me. Best regards, Gina P. Banyard
Re: [PHP-DEV] PDO subclass names
On Tuesday, 23 April 2024 at 15:59, Arvids Godjuks wrote: > A thought crossed my mind, considering that MariaDB and MySQL are drifting > more and more apart with features and nuances of how they work, would it be a > good idea to create an alias to MySQL PDO driver under MariaDB name so we can > create a MariaDB specific implementation down the road and so people can use > DB specific features right away and not be confused why there are errors > between those 2 if someone swaps one for the other. IMHO, this is out of scope for this proposal. If MariaDB wants to maintain a specific PDO Driver they can do so themselves and publish it on PECL, same as how CUBRID (and others) does currently. Best regards, Gina P. Banyard >
[PHP-DEV] Incorrect terminology usage for rounding modes of round()
Hello internals,
While reviewing the PR for the "Adding bcround, bcfloor and bcceil to BCMath"
RFC [1] with the different rounding modes,
I was made aware of the unfortunate wrong terminology usage of
PHP_ROUND_HALF_UP and PHP_ROUND_HALF_DOWN.
Indeed, PHP_ROUND_HALF_UP is implemented as "rounding half away from zero" and
not "rounding half up" (which is also called rounding toward positive infinity).
The behaviour for positive numbers is the same, however for negative numbers
the rounding *is* different.
In the same vein, PHP_ROUND_HALD_DOWN is implemented as "rounding half toward
zero" and not "rounding half down" (/round half toward negative infinity).
Taking -1.5 as our number:
- Rounding half-up: -1
- Rounding half away from zero: -2
- Rounding half-down: -2
- Rounding half towards zero: -1
For a detailed explanation about rounding, the Wikipedia page is of great use.
[2]
And the following rounding calculator on Calculator Soup is useful to check the
differences and behaviour of different rounding modes. [3]
It should be noted that PHP is in good company about being wrong about those
two rounding modes, Java, Python, and Ruby (and probably others) are also wrong
in this regard.
Considering that PHP 8.4 is also adding new rounding modes via the "Add 4 new
rounding modes to round() function" RFC [4] attempting to solve this issue in
this next version of PHP seems like a good idea.
In my discussions with Saki about this issue, it seems that her and Tim have
thought about creating a new enum for rounding modes, looking something like
this:
enum RoundingMode {
case HalfAwayFromZero;
case HalfTowardsZero;
case HalfEven;
case HalfOdd;
case TowardsZero;
case AwayFromZero;
case NegativeInfinity; // or case Floor;
case PositiveInfinity; // or case Ceiling;
}
and change the signature of round from:
round(int|float $num, int $precision = 0, int $mode = PHP_ROUND_HALF_UP): float
to
round(int|float $num, int $precision = 0, RoundingMode $mode =
RoundingMode::HalfAwayFromZero): float
and changing the definition of the existing constants to effectively be:
define('PHP_ROUND_HALF_UP', RoundingMode::HalfAwayFromZero);
define('PHP_ROUND_HALF_DOWN', RoundingMode::HalfTowardsZero);
define('PHP_ROUND_HALF_EVEN', RoundingMode::HalfEven);
define('PHP_ROUND_HALF_ODD', RoundingMode::HalfOdd);
This should not cause any BC breaks, while allowing us to potentially implement
the half up/down rounding modes properly, and deprecate the existing rounding
constants in the future to get rid of the confusing names.
I wanted to know if anyone has any object to introducing this new enum and
signature change.
The only thing I could think of is if this enum should be in a new Maths (or
Math or just Mathematics to not need to deal with regional difference in the
short spelling of "Mathematics") namespace.
Best regards,
Gina P. Banyard
[1] https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath
[2] https://en.wikipedia.org/wiki/Rounding
[3]
https://www.calculatorsoup.com/calculators/math/rounding-methods-calculator.php
[4] https://wiki.php.net/rfc/new_rounding_modes_to_round_function
Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names
On Friday, 5 April 2024 at 18:00, Tim Düsterhus wrote: > Hi > > I've just written up the follow-up RFC to my previous “Casing of > acronyms in class and method names” thread and I'm officially opening up > the discussion period for it. > > Please find the following links for your convenience: > > RFC: https://wiki.php.net/rfc/class-naming-acronyms > Previous ML discussion: https://externals.io/message/120959#120959 > Related discussion in PHP-FIG: > https://github.com/php-fig/per-coding-style/issues/83 > Thank you for working on this! I agree that this policy change makes sense. I was wondering, however, if there should be a follow-up RFC to normalize the casing of existing classes? This isn't a BC Break in theory as class names are, for the time being, case-insensitive. I know in practice that tooling in the ecosystem normalize the names to be the one as currently defined, so it might produce diffs depending on which version of PHP the tool is ran on. The output of tests could be affected. Maybe this change is better suited for PHP 9? Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] [VOTE] Deprecate implicitly nullable parameter types
On Wednesday, 28 February 2024 at 15:24, Gina P. Banyard wrote: > Hello internals, > > I have opened the vote for the "Deprecate implicitly nullable parameter > types" RFC: > https://wiki.php.net/rfc/deprecate-implicitly-nullable-types > > It will run for two weeks until the 13th of March 2024. > > Best regards, > > Gina P. Banyard I'm happy to announce that the RFC has been accepted unanimously, with 26 votes in favour. Best regards, Gina P. Banyard
Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
On Saturday, 9 March 2024 at 19:44, Jim Winstead wrote: > This may be a dumb question, but what's the process for determining whether > the next significant release of PHP will be a minor version or a major > version? If the adherence to semantic versioning is meant to be strict, it > doesn't make any sense to vote on what version something like belongs to, > because then you're saying that whether a BC break is significant enough to > merit an increase to the major version is up for vote. We don't follow semver and never have. There have been BC breaks in every single minor version of PHP since PHP 4. The general attitude is that minor BC breaks are OK in minor versions and must be clearly documented. I will also mention that most programming languages to not follow semver and instead have a set number of versions a deprecated feature exists before being removed, Python being the most famous example. There is no process on how or when a major version should occur and AFAIK it has always been a core developper choice when to push for a version to be a major. Me, and some other members of the Foundation, currently don't see the immediate benefit of having a major version soon. For me, what would cause the roll-over to PHP 9 is converting streams from resources to objects as this not only has a relatively large impact on userland (that we can talk about how to mitigate) but also impacts every single PHP extension that uses streams in some capacity. I also have another selfish reason for wanting to delay PHP 9 for at least another minor version as I still have a large language semantic RFC (in the vein of the container/offset one I just posed) I want to do, which I'm not sure I'll have ready in time before the feature freeze of PHP 8.4. Best regards, Gina P. Banyard
Re: [PHP-DEV] [Pre-RFC] Improve language coherence for the behaviour of offsets and containers
On Monday, 11 March 2024 at 17:26, Rob Landers wrote: > I’m still reading the RFC, but here: > https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md#objects > > You list “appending” twice. Indeed, fixed. I have also fixed another small mistake in the RFC that used offsetWrite() instead of offsetSet() for the method name of the DimensionWrite interface. Best regards, Gina P. Banyard
Re: [PHP-DEV] [Pre-RFC] Improve language coherence for the behaviour of offsets and containers
g weird key types. > > * I feel like some of the sections could benefit from more short code > examples. Eg, What the heck does fetch-append on a null even look like? That > would help illustrate why the current behavior is weird, or why some things > need to stay non-obvious because they're used in odd cases. (Like how > $a[1][2] is a by-ref fetch internally, something most people don't think > about.) > I find having too many examples makes RFCs difficult to read and parse, and I prefer to use them sparingly for when they are really needed. Just for clarity but $a[1][2] is only a by-ref fetch for write operations, if it is a read operation those are performed in sequence. Fetch-append on null is not really weird, it just appends the given value (/null if no assignments happens) and provides a reference to it. See https://3v4l.org/UPg3P > * What would the changes to ArrayObject mean for a backing object that uses > hooks on some properties? It says __get/__set would be bypassed. Would hooks > also be bypassed? (I have no clue what the preferred logic here is, honestly. > Just thinking aloud and hoping hooks pass so that we have to think about > this. :-) ) The current behaviour by-passes __set() and __get() because it works with the property HashTable directly. My current PR to fix all those weird behaviours is to use the write_property object handler with ZEND_GUARD_PROPERTY_SET guard set. I don't know how hooks are implemented so Ilija should be able to determine how this works exactly, but my guess is that it should "just work" with set hooks being called. > > Again, thank you for your work on this, and I hope it passes easily. > > --Larry Garfield Hope I've answered the questions you had. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int
On Saturday, 9 March 2024 at 16:00, Larry Garfield wrote: > I am still opposed to this. Logically, ceil/float/round should be returning > ints, not floats. Only returning ints if it was given an int is, er, kinda > pointless, as you'll just get back the value you passed in. (Because it's > already rounded/floored, etc.) So this doesn't get us any new type safety, > but does make the return type less consistent than it is today. That's a step > backwards. > > If there's some math reason that we cannot have those functions return int > (someone mentioned there was, but I don't really understand it and the RFC > does not explain it at all), then we should at least keep consistency in the > return type. "Sometimes I have to cast the return value before I can actually > use it in the obvious way, sometimes I don't" is not a good situation. > > --Larry Garfield There are plenty of values that are exactly representable as floating point numbers but not as integers. One short example: $v = 1e10 + 0.6; var_dump($v); var_dump(round($v)); Gives you accurate precision and proper rounding behaviour. 1e10 *cannot* be represented as an integer. So round *must* be able to return a float. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Friday, 1 March 2024 at 06:28, Stephen Reay wrote: > For the third time: I'm well aware of how parameter types work everywhere > else, and that's why I'm asking why the same behaviour isn't being followed > here? > > - You've said you want to avoid boilerplate; and > - You've said you would expect most people to just use the implicit > `same-type $value` parameter; and > - You've acknowledged that the existing 'standard' is that a parameter > without a type is considered `mixed`; and > - You've acknowledged in your RFC that there is a use-case for wanting to > accept a wider type than what a property stores internally. > > So why then is it so unacceptable that the existing standard be followed, > such that a set hook with an "untyped" parameter would be treated as `mixed` > as it is everywhere else? > > Yes, I know you said "widening to `mixed` is unwise". I don't seem to recall > amongst all the type-related previous RFCs, any that suggested that child > parameters widening to `mixed` (either explicitly or implicitly) should be > deprecated, so I'm sorry but I don't see much value in that argument. Deprecating this behaviour would effectively mean, types are now required everywhere, which is an unreasonable proposition. The "implicit" widening to mixed is something that got introduced _after_ typing was introduced to PHP, and quite "late" even (in 7.2) considering typing objects/arrays has existed since PHP 5. [1] I don't think it's unreasonable that if property access hooks only work on typed properties, having no type means the type of the property and if you want to widen the type you _must_ specify a type. Especially if you want the backing type to be mixed well you are just required to write a typed property with type mixed, same as readonly. Best regards, Gina P. Banyard [1] https://wiki.php.net/rfc/parameter-no-type-variance
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
On Saturday, 2 March 2024 at 21:10, Kamil Tekiela wrote: > Hi Internals, > > I would like to start a discussion on a new RFC > https://wiki.php.net/rfc/deprecate-get-post-sessions > > Please let me know whether the idea is clear and the RFC is understandable. > > In particular, I am looking for any feedback as to why this is a bad > idea. The primary motivation behind this RFC is to reduce potential > security pitfalls. > > Regards, > Kamil Tekiela I think this makes sense to me. I would possibly move the deprecation of the SID constant from the mass deprecation RFC to this one, as I would be very odd to have this accepted but not the latter. Best regards, Gina P. Banyard
[PHP-DEV] [RFC] [VOTE] Deprecate implicitly nullable parameter types
Hello internals, I have opened the vote for the "Deprecate implicitly nullable parameter types" RFC: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types It will run for two weeks until the 13th of March 2024. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
On Tuesday, 27 February 2024 at 23:17, Larry Garfield
wrote:
> I genuinely don't understand the pushback on $value. It's something you learn
> once and never have to think about again. It's consistent.
>
> Ilija jokingly suggested making it always $value, unconditionally, and
> allowing only the type to be specified if widening:
>
> public int $foo { set(int|float) => floor($value); }
>
>
> Though I suspect that won't go over well, either. :-)
Same, I don't understand the pushback on $value, for me this seems clearer and
less confusing than the existing $this variable when I was first learning about
OOP.
And I would be in favour of just making it always $value, if people feel that
strongly about being able to name it with a custom name they could propose this
as a follow-up RFC.
One thing the RFC should note, which I would expect to be the same as the array
cast, is how do backed/virtual properties interact with
get_mangled_object_vars()
Best regards,
Gina P. Banyard
Re: [PHP-DEV] is this thing on?
On Monday, 26 February 2024 at 11:53, Daniil Gentili wrote: > > IMO sending an email is not a gigantic barrier to entry, as can be seen by > the often low (technical and overall) quality of the replies to many of the > threads on this list. Yet people complain about it being a barrier to entry, and a barrier to contributing to the project. > I really don't think that a modern discussion system can afford to randomly > loose messages: mailing lists should not be used in 2024. This is a take and a half, a lot of self-hosted modern discussion system still require an email server and list. Moreover, internals is far from the only mailing list that contributors/core devs rely on. > Large projects like PHP will still inevitably attract attention, regardless > of whether github or mailing lists are used; I personally dislike mailing > lists not because they are difficult to use, but because they are simply > broken: every time I had to deal with any mailing list, including this one, I > had both incoming and outgoing deliverability issues related either to > DKIM/DMARC, or some other issue caused by modern anti-spam measures that > mailing lists do not account for. I'm sorry this has been your experience, but I never really had any issues with mailing lists, and they have always just worked TM Part of the issue is that we were forced to migrate the mailing list on short notice. And I do agree that certain things the list does about DKIM/DMARC is less than optimal. However, demanding to change the workflow of core developers for _your_ convenience is, not a good way of moving change forward. I find it akin to being a new hire at a large, established company and storming into a meeting of the board of directors within your first week of working to demand change because the way it is currently being operated is "shit". I can let you imagine the fallout of such an action if attempted in real life. Yes, the list is far from ideal, but it is an established process that has somewhat worked and people have integrated this into their workflow. Are there better options? Sure. But shouting "just use GitHub discussion", or whatever $myPreferedPlatformOrMethod is not conducive to change. For us to move away from the internals list you *must* have core developer endorsement for the new solution. And, with people I have talked to, me included, find GitHub discussions to be ill-suited. It probably works perfectly for a library, tooling, or projects built with PHP and I'm happy for projects where it is a good fit. What is the purpose of the list, and internals? I'm not exactly sure, as it seems to have morphed and shifted over the course of its existence. Is the objective is to have core developers interact on it willingly by having technical discussion which might go over most people head? Is the objective just for people to be able spit ball ideas as an initial stage on a wide-reaching platform with minimal interaction from core developers? Is the objective to just propose, announce, and discuss RFCs and vote on them? etc. Probably each of these objectives require different solutions, and this would probably be a more useful conversation to have. Best regards, Gina P. Banyard
Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions
On Saturday, 24 February 2024 at 11:46, Kamil Tekiela
wrote:
> I would actually be against this change. It's a language construct for
> a reason. Functions can be disabled and overridden, but language
> constructs cannot. Exit is supposed to end the script execution
> without any hidden quirks.
>
> I don't actually see any good reason to make it a function. You can
> very easily solve your pet peeve in userland by simply wrapping exit
> in a function.
> function my_exit(int|string $value):never { exit($value); }
> You can then pass this function as a callable, redefine it in a
> namespace, and it obeys the normal function type juggling rules.
>
> This is reminiscent of Python 2 -> 3 migration with the print
>
> statement to a print function change. While you may think you see good
> reasons to make this change, users may see it as trivial and unworthy
> of all the fuss.
>
> Unless there is some extremely good reason to make exit a function, I
> would advise against doing it.
I'm impressed by the fact that one seems to ignore what my first email says.
It can be a function AND NOT be disabled by the disable_functions INI setting.
It can be a function AND NOT be able to define a custom exit()/die() function
in a namespace, this is similar to assert() which is also not a language
construct (which _can_ de disabled with the disable_functions INI setting).
It can be a function AND NOT have _any_ user facing changes.
The PR is implemented in a way so that there is no BC break at all for
userland, except AST-based tools.
And people have suggested a way to not break AST tools, by transforming exit;
into exit(); at compile time.
I also find it extremely weird that it is acceptable that exit() has its own
completely weird type juggling semantics that break user expectations,
when it looks like a function. What is the reason to force users to know and
learn this weird quirk about exit?
Also, comparing this to the Python 2 to 3 migration with print is *totally*
disingenuous,
you cannot write: exit 10; or exit "Hello"; if you do, you get a parse error.
I am not suggesting to make require, or echo, or print be functions as that
_would_ be similar to the Python 2 to 3 migration, and I agree that would be a
bad idea.
This change just makes the language more consistent and removes one type
juggling context.
I realize that I probably should have just spent time writing an RFC and doing
the discussion directly, as I'm effectively laying out the arguments why we
should do this in an email.
Best regards,
Gina P. Banyard
Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions
On Saturday, 24 February 2024 at 01:57, Juliette Reinders Folmer wrote: > Hi Gina, > > I'm not sure a pet-peeve is a good motivation for creating an (I expect > large) breaking change. > > The upgrade path, I suppose, would be updating calls to `die`/`exit` to > always have parentheses ? Or alternatively changing those calls to new throw > expressions ? > > While that shouldn't be that huge a problem for real codebases (and would be > auto-fixable for adding the parentheses), the bigger problem I see is the > huge amount of teaching materials, tutorials and blog posts using the > versions without parentheses which will now all be invalidated. I think the > pain and confusion that will cause for a change like this, will linger for > years and years. > > Smile, > Juliette I didn't actually know one could do exit; But like I said, it is extremely easy to support, and the current PR does support it by hooking into the undefined constant code in the engine. I don't have strong opinions about removing support for this. However, I do have strong opinions about changing the type juggling semantics of exit() to be the usual ones, because the current one is just confusing. I am also not sure what would make this a large breaking change, as changing this from a language construct to a function provides us with more capabilities. Best regards, Gina P. Banyard
[PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions
Hello internals, I've been having this mild annoyance with exit()/die() since I wrote a CLI script using a boolean $hasErrors variable to know if the script failed or not and to indicate if the script failed via a non-zero status code by doing: exit($hasErrors); However, it turns this doesn't work, because exit() will cast everything that is not an integer to a string, something that I find surprising but also weird as it will not type error on resources or array but rather print the warning to the CLI. Anyway, yesterday I decided to put on my mad scientist lab coat and make this a reality, I have a W.I.P. PR here: https://github.com/php/php-src/pull/13483 I hear you, but what about exit; ?! Do not worry exit; is still supported! It only requires a _tiny_ bit of dark magic to achieve this! exit; would just be interpreted as a fetch to a constant, so when attempting to access the undefined exit/die case-insensitive constant we just need to exit as if we were calling the function! Having exit and die be functions gives us access to some interesting functionality, such as defining exit() in a namespace, or removing it via the disable_functions INI setting (the latter allowing us to define a custom global exit() which could be useful for testing that a function actually calls exit). We can also pass it like any other callable and reflect on it with reflection. Finally, this removes the T_EXIT token and ZEND_EXIT opcode freeing one slot. The W.I.P. PR implement every possible restriction: - not being able to declare an exit()/die() function - not being able to disable them - not being able to define a constant named exit/die Maybe it would be wise to deprecate using exit as a statement to be able to get rid of the undefined constant magic handling. Anyhoot, before I spend more time on this and write a proper RFC, do people think this is a good idea or not? Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
Hello internals, I updated the RFC to encompass all the feedback: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types Let me know if there are any final remarks before we start the vote sometime next week. Best regards, Gina P. Banyard
[PHP-DEV] Resolving self and parent types at compile time
Hello internals, I have an outstanding PR where I implemented resolution of the parent and self types at compile time. [1] The reasoning for this is to attempt to add various methods to ReflectionType, such as isCovariant/isContravariant and other type relation methods. Currently, we cannot do this easily, as we need a "scope" with the ReflectionType to resolve the relative class types self, parent, and static. The current implementation uses two new bit flags to mark the type as self and parent, to be able to preserve BC with existing code relying on the names self/parent. However, we are limited in flag numbers available and using two bits for this seems wasteful. The question: Is it an issue if the self and parent types are resolved at compile time? (when possible) In its simplest form, this would affect error messages (such as type errors) and also the compile time type redundancy check. [2] Note: traits and unbound Closures would still require a way to provide the "scope" but those seem to be cases of limited use for analysing/comparing ReflectionTypes. Best regards, Gina P. Banyard [1] https://github.com/php/php-src/pull/11460 [2] If a class Foo declares a method with union type Foo|self no compile time error is thrown at the moment, this would change as self would correspond to Foo and the type would be Foo|Foo which is redundant
Re: [PHP-DEV] ArrayAccess and array_key_exists function
On Monday, 19 February 2024 at 12:32, Ondřej Mirtes wrote: > Hello everyone, > I was recently surprised that ArrayAccess does not work with > array_key_exists() function. > > I am aware that ArrayAccess objects cannot be made to work with many array > functions because it does not provide a way to iterate over its keys, you can > only ask for and set specific previously known keys. > > But it could be made to work with array_key_exists(), because it already > works with isset() and there’s a direct method that could be used for this - > offsetExists(). > > The use case I have in mind is that sometimes libraries that originally use > “array” in return types want to switch to objects and they make these objects > to implement ArrayAccess, for maximising the backward compatibility with the > old version. This mostly works, except for array_key_exists(). > > Do you think we could add support for ArrayAccess objects in the 2nd > parameter of array_key_exists() function? > > Thank you. > > Ondřej Mirtes Hello Ondřej, I'm been working on overhaulling the semantics of "container" objects as ArrayAccess can have some peculiar behaviour, but this is because the underlying engine handlers are also complex. I think this change makes sense and will keep it in mind/add it to my RFC. Best regards, Gina P. Banyard
Re: [PHP-DEV] automatic formatting checks for pull requests?
On Saturday, 17 February 2024 at 22:18, Ilija Tovilo wrote: > Right. Consistent code style is nice, but what we have now is really > not that bad. There are a couple things I'd want if we enforce code > style: > > * Fixing the style should be easy, running a single command without > first pushing to CI. > * It should be fast too, so that I can easily run it for every commit, > preferably even on-save in my editor. > * The new code style should be applied only to newly added sections or > changed code, not entire files. Otherwise, we'll have many changes in > large files, with endless merge conflicts when merging up from lower > branches. Surely the best way is to apply the formatting tool on all branches that are supported (even in security support). Have them be merged upwards, and then add the revisions of the commits to a .git-blame-ignore-revs file so that git blame doesn't care about them. This should resolve the issue of making future merges difficult. Best regards, Gina P. Banyard
Re: [PHP-DEV] Re: [RFC] OOP API for cURL extension
On Saturday, 17 February 2024 at 07:41, Kalle Sommer Nielsen
wrote:
> Hi Sara
>
> Den tors. 15. feb. 2024 kl. 21.08 skrev Sara Golemon poll...@php.net:
>
> > * Better typing for setOpt() methods.
> > Comment: Yep, this is a good and fair point. It's going to take a little
> > more dicing up of the current implementation, but hopefully not too rough.
> > Proposal: Keep untyped setOption() method (1/ Easier migration of existing
> > code, 2/ Some options may prove difficult to type), but add:
> > * CurlHandle::setOptionBool(int $option, bool $value): CurlHandle
> > * CurlHandle::setOptionInt(int $option, int $value): CurlHandle
> > * CurlHandle::setOptionString(int $option, string $value): CurlHandle
> > * etc... as needed, will this get weird when we get to Array since there IS
> > a setOptArray? Maybe we just don't mirror that one, or we call it
> > setOptionMany(). Yeah, I like Many for the multiple option set, and Array
> > for the single option of array type.
> > Internally, the setopt handler will be split by type so that each typed
> > setting can call explicitly, and the untyped one can call all.
>
>
> What about making the CURL options an enumeration? It would allow us
> to typehint the setOptions() method and we can also make it backwards
> compatible with the existing global constants:
> `php public function setOption(CurlOption|int $option, mixed $value): static
> { if (is_int($option)) { $option = CurlOption::createFromConstant($option); }
> // ... }`
>
> The enumeration would then have a static method to transform the
> global constant into a native type (which we can do internally).
> Naming is obvious just TBD. The biggest potential issue I can see with
> this approach is the many conditionally defined constants from older
> CURL versions/feature flags from compile time.
>
> From the many type variants of setOptions(), I am uncertain about
> that, because with an enumeration, we would still need to have some
> sort of whitelisting of what options can be passed into the method.
>
I was also going to suggest to use enums for the options, and have them be
grouped by what value type they need.
This would simplify the C implementation a lot, as most of the logic to handle
the options and the value type would be done by the engine and ZPP.
I don't think it is _that_ problematic to have enum cases be conditionally
defined as trying to use a case/constant that does not exist already throws an
Error in PHP 8 if the constant does not exist.
I will note that this approach _technically_ breaks the handling of options
that require a callables, as the callable is checked to exist _when_ attempting
to call it and not when actually passing it to curl_setopt.
But this should change anyway if I merge my PR which "fixes" this. [1]
Best regards,
Gina P. Banyard
[1] https://github.com/php/php-src/pull/13291
Re: [PHP-DEV] automatic formatting checks for pull requests?
On Saturday, 17 February 2024 at 11:24, Hans Henrik Bergan wrote: > Can we add automatic formatting checks for pull requests? > Made a PR: https://github.com/php/php-src/pull/13417 > > php-src use "tabs" instead of "spaces", that is... quite unusual, > and I'm probably not the first person to accidentally use spaces > instead of tabs, ref > https://github.com/php/php-src/pull/13401/files/d64a8ccdc1d21576827059ee86c0fa073c95ffcc#r1492699756 That's quite standard in the C world AFAIK, yes it's not what is standard for PHP written code but that's kinda irrelevant. It would be nice to have some formatting rules to harmonize the codebase as it is somewhat the wild west, but as far as my understanding goes is that Clang format struggles to understand our codebase (namely macros) and is difficult to set-up for php-src. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] [VOTE] Add http_(get|clear)_last_response_headers() function RFC
On Tuesday, 30 January 2024 at 20:52, Gina P. Banyard wrote: > On Monday, 29 January 2024 at 11:59, Gina P. Banyard g...@gpb.moe wrote: > > > Hello internals, > > > > I just opened the vote for the Add http_(get|clear)_last_response_headers() > > function RFC: > > https://wiki.php.net/rfc/http-last-response-headers > > > > Vote will run for two weeks and end on the 12th of February 2024. > > For reasons, I do not comprehend, this email got somehow lost. > > So I'll extend the vote for 2 days until the 14th of February 2024 I'm happy to announce that the RFC has been accepted with 15 votes in favour and 1 against it. Best regards, Gina P. Banyard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add http_(get|clear)_last_request_headers() function
On Tuesday, 30 January 2024 at 08:48, Nicolas Grekas wrote: > > In Symfony's HttpClient, we use stream_get_meta_data($h)['wrapper_data'] to > access headers, so there is already a way to get them using nothing but > local scope. > > This makes me wonder why, in "rejected ideas", you wrote this? > > > One suggested idea was to provide those headers via a by-reference entry > > to the stream context. > > > > Maybe we don't need anything but to promote what works already (this > "wrapper_data" entry)? The issue is this requires you to have a stream in the first place. file_get_contents() doesn't return a stream, and if the request fails fopen(), by default, returns false. If you do have a stream, then yes stream_get_meta_data() is better, but the objective of this addition is to replace the $http_request_header variable so that it can be removed. This is a rather fringe feature, and thus I expect these functions to also be a fringe feature. Best regards, Gina P. Banyard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Add http_(get|clear)_last_response_headers() function RFC
On Tuesday, 30 January 2024 at 21:05, Kamil Tekiela wrote: > I think it might be even better to extend it by 2 weeks. It looks like > people were unaware that the voting has started on this RFC. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php I started the vote started yesterday. I don't see a point in extending it by two weeks to have a total voting of 4 weeks + 2 days. Best regards, Gina P. Banyard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] [VOTE] Add http_(get|clear)_last_response_headers() function RFC
On Monday, 29 January 2024 at 11:59, Gina P. Banyard wrote: > Hello internals, > > I just opened the vote for the Add http_(get|clear)_last_response_headers() > function RFC: > https://wiki.php.net/rfc/http-last-response-headers > > Vote will run for two weeks and end on the 12th of February 2024. > > Best regards, > > > Gina P. Banyard For reasons, I do not comprehend, this email got somehow lost. So I'll extend the vote for 2 days until the 14th of February 2024 Best regards, Gina P. Banyard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Tuesday, 23 January 2024 at 16:37, Larry Garfield wrote: > On Tue, Jan 23, 2024, at 2:18 AM, Gina P. Banyard wrote: > > > I fundamentally disagree with the logic that we somehow need to "plan" > > deprecations around how much time we need to provide users to upgrade. > > > I categorically disagree here. PHP has a terrible reputation, even among its > own boosters, for breaking people's stuff and making upgrades harder. That is > partially deserved, partially not. (I've written in defense of Internals' > improvements extensively.) But as a project we need to consider both the > practical and social impact of any breaking changes. PHP has a terrible reputation because it didn't try to fix any of its crap for years. PHP has a terrible reputation because it added random ill designed stuff at random prior to the RFC process. PHP has a terrible reputation because it has insane bonkers semantics. PHP has a terrible reputation because its image is stuck in 2005. PHP has a terrible reputation because of projects written in PHP having "bad" codebases. etc. etc. I've stopped counting how many times I've been sent "PHP: a fractal of bad design" [1], how many times have people have brought up to me the fact PHP is the only language they know that undeprecated something (for reference is_a() in 5.1), and other countless stuff that I need to hear semi often. Internals is blamed for making upgrades hard, the life of library maintainers hell, and everything that could be assigned blame to internals. But I have never seen internals tell userland to promote deprecations to exceptions, userland came up with this, and uses this as a tool to harass library maintainers. Maybe I'm just weird, but I don't actually care that projects still use PHP 7, 5, 4, or 3. Because there will always be such projects, and basing my decisions on those makes no sense to me. It helps that I also hear people that are satisfied and happy with the language being tighter, but those are rarely said publicly, because there is no need to complain online when one has nothing to complain about. And again, I frankly don't believe that providing 2, 3, 5, 10 years of deprecation before a removal is effectively different from providing 1 year. People will either fix it immediately, or leave it until the end of time and still make a fuss about it. > > You assert that this is 1-2 orders of magnitude less impactful than undefined > vars or null string params were. I have no data on that off hand either way, > so cannot confirm or deny that estimate. (If you do, that would be very > helpful. No sarcasm, it really would.) It is definitely more > tooling-handleable, and it sounds like there's ample existing tooling for it, > so that's great and will help, but as we've noted many times, people using > good tooling are the minority. I don't need data to know this change is less impactful. Undefined vars requires either tracking the source of the first usage, or guarding every usage with a null coalesce operator. Implicit coercions require the same thing, either tracking the source, guarding every usage, or doing the worst option to just chug an explicit cast in front. And both of these things can happen countless times all over the code base, thus flooding logs. Compared to this change, which requires changing the unique definition of the offending function/method signature. I cannot comprehend how at the same time we need to treat users as capable, intelligent, knowledge people when introducing features. And at the same time consider them to be incompetent, and lacking skills to use tooling. For this deprecation the tooling _already_ exists, if people don't want to use it, why? If people don't know about it, why? If people don't trust it, why? This is different from a bunch of other changes where any tooling would be brand new. > > There is indeed a related discussion around scheduling, deprecation timelines > in general, etc. As I said, I've tried to start that discussion in the past > and was mostly ignored. > > Maybe "all deprecations last for X releases, whatever the number" is a good > policy to have; I don't know. Deciding now that there will be an 8.5 and then > a 9.0 is also a viable option, which will also give 2 years grace period for > users to get up to speed on this change. That's the entire point of > deprecations. Maybe because fixed major release cycles for a programming language is just a bad idea? Because what does a "major" release entail for a programming language? And if someone wants to deprecate something in 8.5 what do we tell them? No? PHP is an open source project, people come and go, and start contributing at different times. And telling someone nah sorry you should have started contributing 3 years ago to be able to make this ch
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Tuesday, 23 January 2024 at 02:45, Juliette Reinders Folmer wrote: > On 23-1-2024 3:18, Gina P. Banyard wrote: > > > The RFC notes that PHPStan and friends have an easy flag to make the > > > change, which is great, but still that's a minority of PHP devs that even > > > know to use static analysis. > > > One does not need to use a static analyser to determine or fix this > > > issue, indeed, I didn't even mention static analysers in the RFC as > > > PHP_CS_FIXER is a tool for enforcing coding styles and is capable of > > > fixing this issue. > > > This tool and other code formatting tools are used more widely and for > > > longer than static analysers. > > While I concur that too few devs use the helpful tooling available to > them, I can already tell you that PHPCompatibility for PHP_CodeSniffer > will be able to detect and flag code subject to this deprecation without > problems and I will make sure the sniff is available ahead of the PHP > 8.4 release (providing the RFC passes). > > And the Slevomat Coding Standard for PHP_CodeSniffer already contains > the `SlevomatCodingStandard.TypeHints.NullableTypeForNullDefaultValue` > sniff to auto-fix non-nullable typed parameters with a `null` default > value to be nullable typed as well, so it's not just CS-Fixer which can > help with this. I had a hunch that PHP_CodeSniffer was able to handle this already, I just couldn't find the correct sniff. :) I'll mention it if/when I update the RFC text. Best regards, Gina P. Banyard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Monday, 22 January 2024 at 18:53, Larry Garfield wrote: > I am in support of this change. My only concern is timeline. This RFC would > deprecate it in 8.4, and presumably support would be removed in 9.0. While we > haven't discussed a timeline for 9.0, historically the pattern is every 5 > years, which would put 9.0 after 8.4, which means only one year of > deprecation notices for this change. There is no reason as to why 9.0 should come after 8.4, and I fundamentally disagree with the logic that we somehow need to "plan" deprecations around how much time we need to provide users to upgrade. To this day, I have never been provided any evidence that longer deprecation times actually lead to users upgrading their code sooner and not delay the inevitable. We were even told to shunt mass deprecation RFCs for 8.0 to 8.1, effectively reducing how much time users have to upgrade for the sake of simplifying the migration from 7.4 to 8.0. The idea for this RFC was floated around the time of PHP ***7***.4, but this was deemed too soon due to cross version compatibility. Moreover, asking core developers to magically figure out all the various ways PHP is bonkers or broken in a specific narrow time frame, just so userland can have X version where the deprecation exists until removal, is unreasonable. If this is the model that we should seek, then we should *completely* move away from our current versioning system and do something more like Python that provides 2 version where a feature is deprecated before removing support. E.g. features deprecated in Python 3.9 were removed in Python 3.11. As such, I will not entertain this idea of timelines and when it is the "right time" to deprecate something for it to be removed at the "right time". If this is something people feel strongly, an RFC to change what our versioning is and means should be done instead. > Given the massive amount of code that built up between 5.1 and 7.1, and 7.1 > and today, I worry that a year won't be enough time for legacy code to clean > up and it would be another "OMG you broke everything you evil Internals > !" like the "undefined is now warning" changes in 8.0. (In > both cases, well-written code any time from the past decade has no issue but > well-written code is seemingly the minority.) I find this comparison disingenuous, fixing undefined variables is one, if not two orders of magnitude harder than fixing this issue. Fixing implicit null to scalar types coercions for internal functions causes way more havoc than this for legacy codebases, and yet we have consistently maintained the rationale for the deprecation. While I do take into consideration the impact RFCs can have on existing code bases, I consider having clear, easy, and comprehensible semantics to be way more important than supporting some complicated and confusing semantics for the sake of BC. There will always be code running on a completely outdated version of PHP due to whatever reason. And refusing to fix the language and its semantics for the vast majority of new code that is going to be written in it feels like a bad decision to me. Especially if fixing it results in engine simplifications. We are our own project, and we need to make choices for the sake of the health of the project, and this means removing stuff in a reasonable timeline. I personally don't work on PHP to do legacy maintenance and keep running it at all cost, if I did want to do this I'd be writing COBOL. I work on PHP because I believe it has a long future ahead of itself, and that new people will learn it and use it. And forcing those people to need to learn, and remember bazillions of gotchas really doesn't sound fair to them IMHO. > The RFC notes that PHPStan and friends have an easy flag to make the change, > which is great, but still that's a minority of PHP devs that even know to use > static analysis. One does not need to use a static analyser to determine or fix this issue, indeed, I didn't even mention static analysers in the RFC as PHP_CS_FIXER is a tool for enforcing coding styles and is capable of fixing this issue. This tool and other code formatting tools are used more widely and for longer than static analysers. Best regards, Gina P. Banyard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
