Re: [PHP-DEV] [Early Feedback] Pattern matching
On Sat, Jun 22, 2024 at 10:16 AM Brandon Jackson wrote: > > > 8. Capturing values out of a pattern and binding them to variables if > > > matched > > > Ok I think that's stepping a bit far out of scope. Maybe `is` should > > > simply check and not have any side effects. > > > > As above, this is core functionality of pattern matching for ADTs, as well > > as a core feature of every other language that has pattern matching, I > > believe. It's not out of scope, it's core scope. > > Ok, it just seems like a rift between expectations and reality. When > looking at things like this, if it is not actually something that's > new to me, I like to try to put myself in the shoes of someone who it > would be new to. Why? Because there are things that you can assume a > syntax does, and there are things you would only know a syntax does by > reading the docs (if it's not buried too deeply and you can find it). > > I would never have assumed that there was a pattern to be appended to > `$foo is Bar` that would automatically assign one of its properties to > another variable if there was a match. But I guess that comes from > ignorance as I haven't had the luxury of familiarizing myself with a > language that does this. So if it is a common thing then I will chalk > it up to a bad assumption of mine. Hi Brandon, Something doesn't sit right with me when an argument is made that something should be in this RFC because it's needed for another, future RFC (in which case, it seems like it should be part of that RFC), but in this particular case, one doesn't need to ever care about ADTs to justify binding being a part of a pattern matching RFC. Without a familiarity of the concept, I think it's very easy to view pattern matching as syntactic sugar for type or shape assertions: in other words, it simply provides another way to ensure type safety. Believe me, I've made the same mistake! Naming things is hard, and "pattern matching" as a name just intuitively feels like it should just be about the checking. But pattern matching's value is in type checking is incidental, and I think a core thing to note from the preamble of the RFC is the following: > In a sense it serves a similar purpose for complex data structures as regular > expressions do for strings. Pattern matching's core purpose is to extract data from a matched data structure, and just as regular expressions have limited value without matching groups, pattern matching is similar without binding. I think it would be difficult to think of an implementation of regular expressions without matching groups, and similarly it would be difficult to think of a useful implementation of pattern matching without the ability to extract the data from the matched data structure. Because of this, every language that implements the concept also includes binding. Hope this helps, Mark Trapp
Re: External Message: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
On Wed, Apr 10, 2024 at 9:59 AM Jeffrey Dafoe wrote: > > > On Wed, Apr 10, 2024 at 4:01 PM Erick de Azevedo Lima > > <mailto:ericklima.c...@gmail.com> wrote: > > Maybe if such a feedback was given before and it was decided to go for a > > trimmed version of the feature, maybe Ilija/Larry could have had less work > > to implement and test all the variantes they've done. I think if a person > > has such numerous concerns, it should be exposed ASAP even if your thoughts > > are not > > totally clear. If you had a chat directly with Ilija/Larry, they would be > > aware of such concerns and would expend efforts to address these concerns. > > > To an outsider, it looks wild when feedback starts coming in right before > > the vote starts. What's even more startling is that there are people with > > voting rights who have never participated in the discussion at all, yet > > have a right to wordlessly affect the vote's outcome. I sincerely hope > > Ilija and Larry's work don't > > go to waste here. > > I hope that the property hooks feature goes through. I've used it in C# and > it reads nice and saves time. > > Waiting until the last minute to express a significant design disagreement is > disrespectful of the time the RFC authors have spent working on this > proposal. It's also counterproductive to the PHP project overall. > > -Jeff Just a friendly reminder that feedback on why people vote against RFCs has been desperately sought after and requested each time a seemingly popular RFC is rejected, and the feedback provided by others for this RFC was done so in good faith, before voting started, allowing the RFC authors to address said feedback should they choose to acknowledge it. And in general, the wider PHP community does not pay attention to RFCs until/unless they come up for a vote. Admonishing people for providing unexpected or negative feedback will have a chilling effect for future RFC attempts, as it's much easier to just silently vote no than to be attacked simply for providing a dissenting opinion at an inconvenient time. - Mark
Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions
On Thu, Apr 4, 2024 at 2:16 PM Bilge wrote: > > On 04/04/2024 16:57, Tim Düsterhus wrote: >> I think it would be reasonable to consider deprecating passing extra >> arguments to a non-variadic function. > > This seems like the only reasonable thing to do, to me. If this were the > case, there should be no need for any new syntax, since we could simply > deny passing extra arguments in the next major, no? > > Bilge I'd caution about being too hasty to deprecate and remove support for this feature without understanding the underlying reasons why it has been used historically, and without providing a better (not just different) alternative for those use cases, lest an impossible upgrade path is created. While the variadic operator should be a 1:1 replacement for using func_get_args(), is it enough of a benefit to force potentially tens of thousands of codebases to change when they both accomplish the same thing? What bad thing happens if PHP continues to support both methods? There is already enough friction to upgrade between major versions. Introducing an optional attribute or syntax allows codebases that care about signature strictness get that safety, while avoiding a potentially costly and onerous upgrade for the community. - Mark
Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions
On Thu, Apr 4, 2024 at 5:43 AM Pablo Rauzy wrote:
>
> Hello all,
>
> First, I'm new here, so let me start by warmly thanking everyone
> involved in PHP development. I've started programming 22 years using it
> as my first programming language, and still enjoy using it a lot :).
>
> I've read the rfc:howto and the first step is to get feedback from this
> mailing list about the intended proposal, so here is a short description
> of what I have in mind:
>
> Currently PHP does not warn when user-defined functions are called with
> too many arguments. Changing this could break a lot of existing code,
> but it would also be a very good verification to catch potential bugs.
>
> I have an idea allowing this feature without breaking any existing code:
> using the void keyword in a function arguments list to strictly limit
> the number of arguments a user-defined function can receive, stopping it
> on the void, which could only be used once and in the last position.
>
> Currently, void is a return-only type so it isn't used in arguments list
> in existing code, so I believe the new behavior would only concern newly
> written code that explicitly wants to take advantage of this feature.
>
> A few examples using functions (the same would apply to class methods,
> callbacks, closures, etc.) :
>
> function foo (void) {}
> foo(42); // warning: foo() expects exactly 0 arguments, 1 given
>
> function bar ($a, $b, void) {}
> bar(1, 2, 3); // warning: bar() expects exactly 2 arguments, 3 given
>
> function baz ($a, $b=null, void) {}
> baz(1, 2, 3); // warning: baz() expects at most 2 arguments, 3 given
>
> I have no knowledge of the PHP internals: would that be feasible without
> breaking things? And, as importantly, would it be a welcome change?
>
> Cheers,
>
> --
> Pablo
Hi Pablo,
I like this concept, but instead of introducing a new syntax, have you
considered leveraging attributes in the same way that PHP 8.3
introduced #[Override]?
#[Nonvariadic]
function foo () {}
foo(42); // warning: foo() expects exactly 0 arguments, 1 given
I think the intent would be clearer and it would avoid introducing a new syntax.
- Mark
[PHP-DEV] RE: Testing new list server
Hello, In the past there was a List-Id header. This seems to be missing now. Is it expected to be added again? Else I will update my mail rules. Kind regards, Mark > -Original Message- > From: Derick Rethans > Sent: Wednesday, February 14, 2024 16:16 > To: Internals@lists.php.net > Subject: Testing new list server > > Please don't be alarmed, we're moving the lists over to a new machine.
Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?
On Tue, Nov 28, 2023 at 12:48 PM Hans Henrik Bergan wrote: > >If the solution is as easy as just converting the encoding of the > source file, then why did we even need to have this setting at all? > Why did PHP parser support encodings that demanded the introduction of > > I've read your question but don't have an answer to it, hopefully > someone else knows. These settings predate the ubiquity of UTF-8, which did not begin to see widespread adoption until the mid-to-late 2000s, and did not reach ubiquity until the mid-2010s: https://en.wikipedia.org/wiki/Popularity_of_text_encodings mbstring.script_encoding was introduced with this commit and released in PHP 4.3 (renamed to zend.script_encoding in PHP 5.4): https://github.com/php/php-src/commit/f30b722f14521fbad2fabe5fdcaa2b60fe97eebb zend.detect_unicode introduced in this commit, released with PHP 5.1: https://github.com/php/php-src/commit/a8c6b992b8894763c59276c1142971aa9a314500 zend.multibyte introduced with this commit, released with PHP 5.4: https://github.com/php/php-src/commit/ab93d8c621645e05d6a6a431d52ac64eda956673 declare(encoding) appears to predate all of the PHP 4.0 tagged releases, including the pre-release ones. - Mark Trapp -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Why can constructors violate LSP?
On Thu, Nov 23, 2023 at 12:31 Robert Landers wrote:
>
> Hello Internals,
>
> As you may know, an inherited method cannot reduce the visibility of
> an overridden method. For example, this results in a fatal error
> during compilation:
>
> class P {
> public function hello($name =3D 'world') {
> echo "hello $name\n";
> }
> }
>
> class C extends P {
> private function hello($name =3D 'world') {
> parent::hello($name);
> echo "goodbye $name\n";
> }
> }
>
> However, we can make certain methods private anyway, namely,
> constructors (I haven't gone hunting for other built-in methods yet).
> This is perfectly allowed:
>
> class P {
> public function __construct($name =3D 'waldo') {
> echo "hello $name\n";
> }
> }
>
> class C extends P {
> private function __construct($name =3D 'world') {
> parent::__construct($name);
> echo "goodbye $name\n";
> }
> }
>
> To my somewhat trained eye, this appears to violate the Liskov
> Substitution Principle, for example, this now can have hidden errors:
>
> function create(P $class) {
> return new (get_class($class))();
> }
>
> proven by:
>
> $c =3D (new ReflectionClass(C::class))
> ->newInstanceWithoutConstructor();
>
> create($c);
>
> Even though we thought we knew that the constructor was declared public.
>
> I'd like to propose an RFC to enforce the covariance of constructors
> (just like is done for other methods), to take effect in PHP 9, with a
> deprecation notice in 8.3.x.
>
> I'm more than happy to implement it.
>
> Does anyone feel strongly about this one way or the other?
>
> Robert Landers
> Software Engineer
> Utrecht NL
(Apologies: resending because I used the wrong email address to send
to the list)
Hi Robert,
Liskov and Wing explicitly exempted constructors in their original
paper describing the principle:
http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.pdf
> 4.1 Type Specifications
>
> A type specification includes the following information:
>
> - The type's name
> - A description of the type's value space
> - A definition of the type's invariant and history properties
> - For each of the type's methods:
> - Its name;
> - Its signature including signaled exceptions;
> - Its behavior in terms of pre-conditions and post-conditions.
>
> Note that the creators are missing. Omitting creators allows subtypes to =
provide different creators than their supertypes. In addition, omitting cre=
ators makes it easy for a type to have multiple implementations, allows new=
creators to be added later, and re ects common usage: for example, Java in=
terfaces and virtual types provide no way for users to create objects of th=
e type.
(Creators is Liskov's word for constructors, which they later define
in the paper.)
Hope that helps.
- Mark Trapp
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Why can constructors violate LSP?
On Thu, Nov 23, 2023 at 12:31 PM Robert Landers
wrote:
>
> Hello Internals,
>
> As you may know, an inherited method cannot reduce the visibility of
> an overridden method. For example, this results in a fatal error
> during compilation:
>
> class P {
> public function hello($name = 'world') {
> echo "hello $name\n";
> }
> }
>
> class C extends P {
> private function hello($name = 'world') {
> parent::hello($name);
> echo "goodbye $name\n";
> }
> }
>
> However, we can make certain methods private anyway, namely,
> constructors (I haven't gone hunting for other built-in methods yet).
> This is perfectly allowed:
>
> class P {
> public function __construct($name = 'waldo') {
> echo "hello $name\n";
> }
> }
>
> class C extends P {
> private function __construct($name = 'world') {
> parent::__construct($name);
> echo "goodbye $name\n";
> }
> }
>
> To my somewhat trained eye, this appears to violate the Liskov
> Substitution Principle, for example, this now can have hidden errors:
>
> function create(P $class) {
> return new (get_class($class))();
> }
>
> proven by:
>
> $c = (new ReflectionClass(C::class))
> ->newInstanceWithoutConstructor();
>
> create($c);
>
> Even though we thought we knew that the constructor was declared public.
>
> I'd like to propose an RFC to enforce the covariance of constructors
> (just like is done for other methods), to take effect in PHP 9, with a
> deprecation notice in 8.3.x.
>
> I'm more than happy to implement it.
>
> Does anyone feel strongly about this one way or the other?
>
> Robert Landers
> Software Engineer
> Utrecht NL
Hi Robert,
Liskov and Wing explicitly exempted constructors in their original
paper describing the principle:
http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.pdf
> 4.1 Type Specifications
>
> A type specification includes the following information:
>
> - The type's name
> - A description of the type's value space
> - A definition of the type's invariant and history properties
> - For each of the type's methods:
> - Its name;
> - Its signature including signaled exceptions;
> - Its behavior in terms of pre-conditions and post-conditions.
>
> Note that the creators are missing. Omitting creators allows subtypes to
> provide different creators than their supertypes. In addition, omitting
> creators makes it easy for a type to have multiple implementations, allows
> new creators to be added later, and re ects common usage: for example, Java
> interfaces and virtual types provide no way for users to create objects of
> the type.
(Creators is Liskov's word for constructors, which they later define
in the paper.)
Hope that helps.
- Mark Trapp
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Introducing 2 new modes to round function
Once upon a many years ago: https://github.com/php/php-src/pull/1658 It will be nice to see it finally get and implementation On 21/07/2023 21:26, Jorg Sowa wrote: Hello internals! I would like to propose introducing two new modes to the function `round()`: PHP_ROUND_DOWN and PHP_ROUND_UP. Those modes are highly requested as you can see by the comments on round documentation page. First comment mentioning about those modes has 309 votes as of today. Introducing those 2 modes would be complementing to the rounding in this function. Round documentation: https://www.php.net/manual/en/function.round.php My implementation: https://github.com/php/php-src/pull/11741 I'm not sure if such minor improvement requires RFC, but as someone may have some concerns I create this thread to get your feedback. Kind regards, Jorg -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
On 10/04/2023 14:17, G. P. B. wrote: Dan and I would like to propose a new core autoloading mechanism that fixes some minor design issues with the current class autoloading mechanism and introduce a brand-new function autoloading mechanism: https://wiki.php.net/rfc/core-autoloading The existing SPL autoloading functions would become aliases to the new Core ones and will continue to work without any migrations needing to be performed. I fully support this endeavour: I've wanted this for such a long time now. A while ago I was pressured into splitting two of my libraries that provided both function and class/method calls, increasing my maintenance workload. This would allow me to combine them again. Looking at all the points that have already been raised, I think Sara sums up well. I also like Rowan's suggestion of a list of namespace prefixes. In particular, you're already considering the use of maps for even better performance, and Constant and Stream autoloading, as possible future enhancements. Constants in particular is something I'd find particularly useful; and my only concern with this is the increased number of functions compared with a single function that accepts a Type argument (as Aleksander suggests). A couple of general questions: Are there any core functions that should never by overloaded (function_exists() perhaps)? We have the special constants like \MyNamespace\MyClass::class. Would you envisage (or is there value in) equivalent constants like \MyNamespace\MyFunction::function? If there is value, how would that tie in with referencing them as Callables in callback functions? -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 11/04/2023 00:03, Larry Garfield wrote: Here, I'll even give you a concrete example:https://wiki.php.net/rfc/saner-inc-dec-operators This is a good change to clean up an old buggy design. Let's suppose that we were 100% certain it would pass with 100% approval. However, if someone is doing something screwy and buggy it will change the behavior by making previously-kinda-working-but-definitely-buggy code throw a Warning, and later another oddball usage will throw a deprecation, and then eventually in PHP 9 a TypeError. Perhaps not the best example. There's definitely some cases that need cleaning up; but deprecating inc/dec for anything but numeric values is IMO too extreme in what it proposes making it little more than syntactic sugar for the += and -= operators, only working with numeric values. https://wiki.php.net/rfc/saner-array-sum-product might be a better example. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
language developer should care about a commercial company having a 20-year-old legacy system that has no resources to upkeep it's systems? Again with the 20 years. And when did I suggest that should be the role of internals? BUT, the affect of internals changes on legacy code shouldn't simply be ignored; where appropriate, upgrade paths/recommendations should be provided, and the edge cases of those changes should be considered. A small change to core code might have minimal benefit; but could still create hours of extra upgrade work for millions of developers around the world. "they are making sure deprecations are issued well in advance, sometimes through multiple versions and only then the feature is completely removed or made a full-on error" I do wish that this was always the case! -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 21:01, Hans Henrik Bergan wrote: several PHP versions will be maintained for 10 years by third-party vendors. PHP5.6 will meet the 10 year mark by 28 august 2024, and freexian.com maintains PHP5.6 with multiple customers paying 6000€/year for 5.6 maintenance. Canonical intends to maintain PHP7.0 until April 2026 for their Ubuntu Pro 16.04. Canonical intends to maintain PHP7.2 until April 2028 for their Ubuntu Pro 18.04. Canonical intends to maintain PHP7.4 until April 2030 for their Ubuntu Pro 20.04. Canonical intends to maintain PHP8.1 until April 2032 for their Ubuntu Pro 22.04. I'm glad that some people can make money out of all this. The 70+ hours a week that I put in to maintaining my own libraries nets me €16,30 a month from a userbase that averages 120k downloads a day -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 19:04, Arvids Godjuks wrote: I also want to add that PHP is purely developed by open-source contributor efforts who are limited in their numbers and not a lot of them are getting compensated for it (exceptions being specific people working for companies who have a vested interest in PHP development like JetBrains, hosting giants and some others. And now PHP Foundation is there to help people get paid for their crucial roles in PHP project and their dedicated time). Yes we know, and we're very grateful; but that doesn't mean we should be unquestioningly grateful! And some of us are also open-source contributors, not getting compensated for it. We understand; and just as I try to take a professional approach to my OS contributions, and assess the impact of any change that may affect bc, I hope that PHP Internals does the same, but I don't often see that. So am I expected to stay silent when I see potential problems with bc breaks because I should just be grateful? You also have a world on your hands that is changing - everywhere you look things are going for a more typed approach. That's what developers of today expect. That's the reality of how modern libraries are developed and old libraries have been actively migrating to strict type code bases. This code quality improvement absolutely takes a huge load off those developers' shoulders. I'm seeing libraries out there now that basically require PHP 8.1 as a minimum because Enums are all the rage and almost half the libraries I use have introduced them in their code in the latest versions and authors just flat-out tell you "use the older version of the lib or update your project" (and I have at least 7 of them in my code already and that project will never run on anything lower than 8.2). Some of the biggest libraries out there have fully adopted SemVer and will bump the minimal PHP version quite aggressively. And will tell you to pay for commercial support or deal with it on your own. And now the Union types are coming and I expect that to get adopted at a rapid pace by everyone and their dog. Yes it is changing, but at different speeds in different companies. Changes aren't being adopted at that rapid pace by everyone and their dog, that's the reality. Just as owning your own house means you need to do the upkeep on a yearly basis or it will become a mess, the same is with code and not maintaining it - eventually, the roof will cave in and the costs of fixing it all will skyrocket. And, frankly, this is the feeling I get from a lot of this thread - the roof has collapsed and people are put into impossible positions of "no, you can't have the time or resources to update the project to the new PHP version, here are 20 KPI's for the next 3 months you need to hit". The codebase was run on a credit of "this will be fixed down the line". Well, the debt collectors now what their debt, their late fees and lawyers want their slice of the pie. Do you think we're unaware of that! But you're suggesting that anybody that isn't using the latest shiny release should be treated as though they don't exist. They're not your problem, so forget about them. Many of those developers would love to upgrade to the latest shiny release, but that isn't always an option every November; that run-up to Christmas can often be the busiest time of year for those developers, the time when they are least in a position to go through an upgrade. Telling them that the debt collectors and lawyers are here isn't going to help them when the people that pay them so they can eat and have a roof over their heads and care for their families is a slap in the face to them when they are torn between business demands and wanting to do technical upgrades. And the attitude of some here on PHP Internals that we should just ignore those who can't develop in greenfield environments using the latest shiny, or that it should just be a simple upgrade step from last version to current release... that's the equivalent of having unit tests that only test the happy path. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 18:17, Pierre Joye wrote: I understand agency work, managers pushing new features instead of a cleaning some legacy. however years of ignoring deprecation notices (very few were introduced right before 8.0). Most of them could have been fixed within a couple of hours in any code base, if they had tests. I would suggest, very very nicely, to review and rethink the development flows of these projects instead of asking php to freeze. We're NOT asking PHP to freeze! We're asking for proper analysis of the effects of these changes on end users, and proper consideration of the time that it will take for end-users to upgrade... and the answer to that is NOT "within a couple of hours". Call it unnecesary overhead if you will, but many tech teams have process flows for their work that don't simply entail "run rector on your codebase and deploy". Even just the admin overheads of raising a ticket for the change, creating a Merge Request, Peer Review, etc can take a few hours of time in many teams. And that's before making the assumption that all older code has a good test suite, and CI pipeline... if it has, then it's probably code that's being updated regularly anyway, by developers that do try to keep everything up-to-date. Nor are end-user developers the only people that are affected. End-user developers typically have the luxury of writing their code for a single version of PHP, so upgrading the version is a step from one version to the next. Library writers don't have that luxury: their codebase normally has to work with a range of PHP versions including the latest release; and any fixes that are made for the latest release still have to work with older PHP versions, which can take significantly more effort to maintain. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Future stability of PHP?
On 10/04/2023 10:48, Andreas Leathley wrote: It would be interesting to know why some people are having such huge problems upgrading their applications, as I think those would often be good stories with something to learn in them. So to the original poster or other people with big problems when upgrading, writing a blog article detailing what happened would be helpful to evaluate if the PHP project could improve something, or even why something broke. Would it really be considered helpful? When I or others like jrf who see the potential problems try to warn about these issues here on Internals, our concerns are generally ignored, or it's considered that we don't want to allow PHP to move forward, or that we're simply scaremongering. We aren't against PHP moving forward; we're not advocating that changes and improvements shouldn't be made. We are saying that they shouldn't be purely technical discussions about implementation here on Internals, but there should also be consideration for the impact on existing userland code. All too many of the changes made in 8.0, 8.1 and 8.2 had no impact assessment, no consideration of how much effort might be required for users to make the necessary changes in their code. Thankfully, I've started seeing some effort again to include a risk analysis or impact assessment in some of the more recent RFCs. And many of those RFCs work on the assumption that all existing PHP codebases are adequately covered by unit tests to identify the points where changes need to be made, and written well enough that any designated fix will always work. But in the real world, that is rarely the case, particularly with older codebases. Too often the RFCs seems to assume the happy path; with testing for edge cases in developers applications after release. > Nowadays there are even tools now like Rector that can help you automatically > upgrade your codebase - that is also a new value proposition. Tools like rector can help, particularly for developers that are specifically upgrading from one PHP version to another; and rector is certainly a game-changer there in the same way that Composer changed the way that we build applications and manage dependencies. Where rector is less useful is if we need to maintain the same codebase across multiple PHP versions, which is the case for many libraries, as well as some of the tools that we use for developing and testing. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Define proper semantics for range() function
On 28/03/2023 00:36, G. P. B. wrote:
Hello internals,
While working on analysing the impact of the changes proposed by amending
the behaviour of the increment and decrement operators (
https://wiki.php.net/rfc/saner-inc-dec-operators) I discovered that the
range() function has some rather lax behaviour that is very unintuitive.
I therefore propose the "Define proper semantics for range() function" RFC
to address the unintuitive behaviour that sees no usage and/or hide bugs:
https://wiki.php.net/rfc/proper-range-semantics
The change propose to throw TypeErrors and ValueErrors for case where I
couldn't find occurrences in the wild and hide bugs, and emit some
E_WARNINGs for cases that are hard to detect via static analysis.
Unlike your changes to the increment operator, I'd love to see this
rationalisation put in place, though like many here I don't see problems
with using a negative step with decreasing ranges, but would consider it
strange for increasing ranges. And I do want to see some
case-consistency when working with string ranges.
I'd love to see it taken a stage (or two) further; returning an iterable
rather than an array (although that would be a bc break); and working
with strings (ASCII only) in the same way that the increment operator
does, so that range('A', 'IV') would be valid, and return `Z` then `AA`,
`AZ` then `BA`, etc.
I am slightly surprised that you make no mention of the odd behaviour of
mixed alphameric strings, e.g. var_dump(range('A1', 'C5')) which returns
a purely alpha array 'A' to 'C'; or var_dump(range('3c', '5e')) which
returns numeric (3, 4, 5); or var_dump(range('1', '1e2')) which treates
`1e2` as scientific and returns 1..100.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [IDEA] allow extending enum
On 29/03/2023 16:43, Mark Baker wrote:
On 29/03/2023 16:31, Davey Shafik wrote:
On Mar 29, 2023, at 06:56, Rowan Tommins
wrote:
On Wed, 29 Mar 2023 at 14:22, Rokas Šleinius
wrote:
Ok so I am trying to find the argumentation here:
This is by design.
The point of enums is to be limiting.
This is clearly an assumption. That statement is not in the docs or
RFC, nor such an oversimplification makes logical sense to me, but
maybe you have a source to back it up..?
From a theory point of view, *any* type definition is about limiting
allowed values. The difference between "mixed" and "integer" is that
"mixed" allows both 'Hello' and 42, but "integer" does not - it
defines a
tighter limit.
In the same way, saying "I accept an error code" means "I accept an
error
code *and nothing else*" - the definition of what is and what isn't an
"error code" is deliberately a *limit* on the values that you accept.
Re: problem in the OP
You are approaching the design of this in a fundamentally wrong way.
The described problem is dealing with error *codes* not *types*
An enum is a type, so that's why George was talking about types. He was
making the same point, in different words, as I did: the relationship
between types implied by the keyword "extends" is not the
relationship you
want in this case.
The set in question is *finite*, as you say of course, but much larger
and different in principle than in the solution you are proposing.
Problem in OP is looking for a way for end users to keep adding new
domains to the error codes passed to the parent system to be handled.
This is the key point - if you pass an error code that didn't
previously
exist, the existing system *won't* be able to handle it.
That's why enums are inherently restrictive: the system wants to be
able to
say "this is the list of error codes I understand, don't give me
anything
else".
If you have a system that accepts the new codes as well as the old
ones,
you can use a union type declaration as George says:
enum AdditionalErrorCode {
case Code_456;
}
class ExtendedErrorHandler extends StandardErrorHandler {
public function handle(StandardErrorCode|AdditionalErrorCode
$code) {
switch ( $code ) {
case AdditionalErrorCode::Code_456:
// handling for new code goes here
break;
default:
// assert($code instanceof StandardErrorCode);
parent::handle($code);
break;
}
}
}
The issue of contention here is that inheritance isn't the correct
mechanism for reusing enum definitions to expand on them. What about
allowing "use" syntax like traits?
enum HttpErrors {
case HTTP_STATUS_400;
case HTTP_STATUS_401;
…
}
enum ApiErrors {
use HttpErrors;
case JsonParserError;
case GraphQLParserError;
}
Now you have ApiErrors::HTTP_STATUS_400 etc without ApiErrors being
is-a HttpErrors.
That would make a lot of sense, and I was just having similar thoughts
myself.
ApiErrors isn't the same enum, or an extension of HttpErrors: it's a
new Enum, but it does include all HttpErrors cases (and methods)
without the need to duplicate code, and any new cases that are
subsequently added to HttpErrors will automatically be incorporated in
ApiErrors.
Another benefit of this approach would be to allow the inclusion of
multiple enums, in the same way that we can include multiple traits.
enum HttpErrors {
case HTTP_STATUS_400;
case HTTP_STATUS_401;
…
}
enum DatabaseErrors {
case RECORD_NOT_FOUND;
case DATABASE_NOT_AVAILABLE;
…
}
enum ApiErrors {
use HttpErrors, DatabaseErrors;
case JsonParserError;
case GraphQLParserError;
}
--
Mark Baker
Re: [PHP-DEV] [IDEA] allow extending enum
On 29/03/2023 16:31, Davey Shafik wrote:
On Mar 29, 2023, at 06:56, Rowan Tommins wrote:
On Wed, 29 Mar 2023 at 14:22, Rokas Šleinius wrote:
Ok so I am trying to find the argumentation here:
This is by design.
The point of enums is to be limiting.
This is clearly an assumption. That statement is not in the docs or
RFC, nor such an oversimplification makes logical sense to me, but
maybe you have a source to back it up..?
From a theory point of view, *any* type definition is about limiting
allowed values. The difference between "mixed" and "integer" is that
"mixed" allows both 'Hello' and 42, but "integer" does not - it defines a
tighter limit.
In the same way, saying "I accept an error code" means "I accept an error
code *and nothing else*" - the definition of what is and what isn't an
"error code" is deliberately a *limit* on the values that you accept.
Re: problem in the OP
You are approaching the design of this in a fundamentally wrong way.
The described problem is dealing with error *codes* not *types*
An enum is a type, so that's why George was talking about types. He was
making the same point, in different words, as I did: the relationship
between types implied by the keyword "extends" is not the relationship you
want in this case.
The set in question is *finite*, as you say of course, but much larger
and different in principle than in the solution you are proposing.
Problem in OP is looking for a way for end users to keep adding new
domains to the error codes passed to the parent system to be handled.
This is the key point - if you pass an error code that didn't previously
exist, the existing system *won't* be able to handle it.
That's why enums are inherently restrictive: the system wants to be able to
say "this is the list of error codes I understand, don't give me anything
else".
If you have a system that accepts the new codes as well as the old ones,
you can use a union type declaration as George says:
enum AdditionalErrorCode {
case Code_456;
}
class ExtendedErrorHandler extends StandardErrorHandler {
public function handle(StandardErrorCode|AdditionalErrorCode $code) {
switch ( $code ) {
case AdditionalErrorCode::Code_456:
// handling for new code goes here
break;
default:
// assert($code instanceof StandardErrorCode);
parent::handle($code);
break;
}
}
}
The issue of contention here is that inheritance isn't the correct mechanism for reusing
enum definitions to expand on them. What about allowing "use" syntax like
traits?
enum HttpErrors {
case HTTP_STATUS_400;
case HTTP_STATUS_401;
…
}
enum ApiErrors {
use HttpErrors;
case JsonParserError;
case GraphQLParserError;
}
Now you have ApiErrors::HTTP_STATUS_400 etc without ApiErrors being is-a
HttpErrors.
That would make a lot of sense, and I was just having similar thoughts
myself.
ApiErrors isn't the same enum, or an extension of HttpErrors: it's a new
Enum, but it does include all HttpErrors cases (and methods) without the
need to duplicate code, and any new cases that are subsequently added to
HttpErrors will automatically be incorporated in ApiErrors.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
On 07/02/2023 20:53, Olle Härstedt wrote: No not really. I'd expect it behave similar to function argument type-hinting in PHP, that is, runtime checks, but where the notation can be used by external tools. The big difference is that the current checking for function arguments is only necessary when a function is called; but that checking for local-scoped variables would be required on every assignment to a variable, or operation that can change a variable value; and that becomes more problematic with the potential need for union types. $mystring = 'I love elephants'; $findme = 'php'; int $pos = strpos($mystring, $findme); // $pos can be an integer or false or when a type can legitimately change int $result = PHP_MAX_INT; ++$i; // $i is now a float -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Typed class constants
Dan, On Sat, Feb 4, 2023 at 8:34 AM Dan Ackroyd wrote: > Hi Mark, > > On Sat, 4 Feb 2023 at 00:22, Mark Niebergall > wrote: > > > > This is also a bigger policy question for other seemingly-abandoned > > RFCs. If it is agreed that a new RFC should be created in this scenario, > > I've added some notes on the page https://wiki.php.net/rfc/howto > > I had some words already prepared from something I will post > separately, but may as well post here also: > > Mailing list etiquette - > https://github.com/Danack/RfcCodex/blob/master/etiquette/mailing_list.md > > Mailing list etiquette for young'uns - > > https://github.com/Danack/RfcCodex/blob/master/etiquette/mailing_list_for_younguns.md > > RFC attitudes - > https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_attitudes.md > > RFC etiquette - > https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_etiquette.md > > Most of the stuff in there is just etiquette rather than rules, so > probably isn't appropriate for the wiki. > > Thanks, these are actually very helpful and insightful. > > > I did leave Benas as an author to give him credit for the work he did. > > Although well intentioned, that's probably quite a no-no. Putting > someone's name on something they don't necessarily agree with is > likely to cause drama. I've added a note on that also. > > > With the reverting, valuable community input was dismissed. An effort > should > > be made to address applicable previous community input instead of just > > reverting it out. > > Probably not. > > It's up to other people to persuade RFC authors why something should > be included, rather than RFC authors having to take time and energy to > justify why they are reverting unapproved edits to their RFC. > > But yep, if you want to do it as part of a separate RFC, go for it. > I'll be doing that as a separate RFC, after the typed constants RFC settles. > > cheers > Dan > Ack >
Re: [PHP-DEV] [RFC] [Discussion] Typed class constants
Benas, On Sun, Feb 5, 2023 at 9:29 AM Benas IML wrote: > [copy of the email that I have accidentally sent to Mark individually] > > Hey, > > As much as I appreciate your enthusiasm and ideas, adding your name on > my original RFC and editing its contents without my approval is not > acceptable. Especially considering that contents of the RFCs are a > direct representation of my stance and views on a particular feature. > As such, I would not like to have my name put on proposals that I have > never discussed nor proposed myself. In this case, I explicitly have > given Máté permission to continue working on this RFC and in taking it > under his wing. > My apologies. Good luck on the RFC. > > That being said, feel free to open a new RFC yourself and copy the > contents of your previous proposal from the wiki's history tab. > I will be doing that. I'll give the typed constants RFC time to settle first. > > Best regards, > Benas > > P.S.: Next time, try also contacting me over Room 11 or GitHub, given > that I rarely check this email. > > Thanks for the updated contact information. > On Sat, 4 Feb 2023 at 02:22, Mark Niebergall > wrote: > > > > Máté, Benas, Internals, > > > > On Fri, Feb 3, 2023 at 7:34 AM Máté Kocsis > wrote: > > > > > Hi Alexandru, Mark, > > > > > > > > > > 1. Why is object type not supported? I can't see a real reason and > also > > > > there is no explanation why. > > > > > > > > > > Sorry for this, mentioning object as unsupported was an artifact from > the > > > original version of the RFC which > > > was created back then when constants couldn't be objects. After your > > > comments, I removed the object type > > > from the list. Thank you for catching this issue! > > > > > > > > > > 2. In the examples for illegal values, it would be good to explain > why > > > > they are not legal. > > > > I don't understand why "public const ?Foo M = null;" wouldn't be > legal. > > > > I think "?Foo" should work the same as "Foo|null" that would be > legal. > > > > > > > > It was there due to the same reason as above. I removed this example > now. > > > > > > I had updated the RFC page, but it looks like the changes were > reverted in > > > > December 2022. The updated version I was working on was: > > > > https://wiki.php.net/rfc/typed_class_constants?rev=1648644637 > > > > > > > > > Yeah, the original author of the RFC was surprised to find your > changes in > > > his RFC ( > https://github.com/php/php-src/pull/5815#issuecomment-1356049048 > > > ), > > > so he restored his original version. > > > Next time, please either consult with the author of an RFC if you > intend to > > > modify the wording, or you can simply create a brand new RFC - even if > it's > > > very similar to the original one (just don't > > > forget to add proper references). > > > > > > > See https://externals.io/message/117406#117460 about contact attempts > that > > were made (with no response), and other discussions about why I used the > > existing RFC instead of creating a new one. Next time I will just start a > > new RFC if an author is non-responsive. This is also a bigger policy > > question for other seemingly-abandoned RFCs. If it is agreed that a new > RFC > > should be created in this scenario, I will update > > https://wiki.php.net/rfc/howto since that scenario is not specifically > > covered. > > > > That being said, the RFC was discussed publicly actively last year, and > the > > RFC was revised based on the public input. With the reverting, valuable > > community input was dismissed. An effort should be made to address > > applicable previous community input instead of just reverting it out. > > > > I will work on a new RFC to follow this implementation to introduce > > inheritance. > > > > > > > > > > The updated RFC looks good, thanks for working on it. You may want to > > > > review the revised version I had worked on for implementation ideas, > and > > > > review the previous conversations. > > > > > > > > > > I also saw your proposal, but to be honest, I'm not that fond of the > idea. > > > This doesn't mean though that you shouldn't create a new RFC or an > > > implementation, as others may find it useful. If you kick off > > > the project, I'll surely try to review your work. > > > > > > > That is fine to break it apart as a future RFC. I have seen too many real > > world use cases where inheritance with typed constants would solve > > problems. See https://externals.io/message/117406#117408 for an > > explanation. Adding typed constants independently adds value, so it > should > > progress. > > > > > > > > > > Regards, > > > Máté Kocsis > > > > > > > Overall, I'm happy to see that this is progressing again, thanks for > > working on it. > > > > - Mark Niebergall >
Re: [PHP-DEV] [RFC] [Discussion] Typed class constants
Máté, Benas, Internals, On Fri, Feb 3, 2023 at 7:34 AM Máté Kocsis wrote: > Hi Alexandru, Mark, > > > > 1. Why is object type not supported? I can't see a real reason and also > > there is no explanation why. > > > > Sorry for this, mentioning object as unsupported was an artifact from the > original version of the RFC which > was created back then when constants couldn't be objects. After your > comments, I removed the object type > from the list. Thank you for catching this issue! > > > > 2. In the examples for illegal values, it would be good to explain why > > they are not legal. > > I don't understand why "public const ?Foo M = null;" wouldn't be legal. > > I think "?Foo" should work the same as "Foo|null" that would be legal. > > > > It was there due to the same reason as above. I removed this example now. > > I had updated the RFC page, but it looks like the changes were reverted in > > December 2022. The updated version I was working on was: > > https://wiki.php.net/rfc/typed_class_constants?rev=1648644637 > > > Yeah, the original author of the RFC was surprised to find your changes in > his RFC (https://github.com/php/php-src/pull/5815#issuecomment-1356049048 > ), > so he restored his original version. > Next time, please either consult with the author of an RFC if you intend to > modify the wording, or you can simply create a brand new RFC - even if it's > very similar to the original one (just don't > forget to add proper references). > See https://externals.io/message/117406#117460 about contact attempts that were made (with no response), and other discussions about why I used the existing RFC instead of creating a new one. Next time I will just start a new RFC if an author is non-responsive. This is also a bigger policy question for other seemingly-abandoned RFCs. If it is agreed that a new RFC should be created in this scenario, I will update https://wiki.php.net/rfc/howto since that scenario is not specifically covered. That being said, the RFC was discussed publicly actively last year, and the RFC was revised based on the public input. With the reverting, valuable community input was dismissed. An effort should be made to address applicable previous community input instead of just reverting it out. I will work on a new RFC to follow this implementation to introduce inheritance. > > The updated RFC looks good, thanks for working on it. You may want to > > review the revised version I had worked on for implementation ideas, and > > review the previous conversations. > > > > I also saw your proposal, but to be honest, I'm not that fond of the idea. > This doesn't mean though that you shouldn't create a new RFC or an > implementation, as others may find it useful. If you kick off > the project, I'll surely try to review your work. > That is fine to break it apart as a future RFC. I have seen too many real world use cases where inheritance with typed constants would solve problems. See https://externals.io/message/117406#117408 for an explanation. Adding typed constants independently adds value, so it should progress. > > Regards, > Máté Kocsis > Overall, I'm happy to see that this is progressing again, thanks for working on it. - Mark Niebergall
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 23/01/2023 14:06, G. P. B. wrote: However, the whole point of this RFC is to*remove* cognitive burden for developers, so they don't even need to be aware of this "feature" and not get surprised when it kicks in. Moreover, by your logic, you wouldn't care if we removed support for alphanumeric strings and only let the PERL increment kick in for purely alphabetical. While convenient for you, someone might actually use this feature on alphanumeric strings, and we're back to "why is my use case being removed while that other just as weird one remains". I make no judgement on alphanumeric strings, other than I can't see any use case for it myself, so I won't allow my objection be considered hypocritical; and your definition of my use case as "weird" is highly judgemental. Bijective numeration using the letters of the alphabet has a long and ancient tradition, pre-dating our modern numeric Hindu-Arabic system using base 10 for place/value notation by many centuries. The Abjadi system used the 28 letters of the Arabic alphabet; similarly the ancient Greeks and Hebrews, the Armenians; by Russia until the early 18th Century (each culture using their own alphabet). It's ironic that the Romans used a very different system, even though our modern western alphabet is based on the Roman alphabet. These civilisations didn't consider their alphabetic numeral system "weird". How many of the irregularities and idiosyncracies of alphanumeric strings could be resolved by not trying to cast them as a numeric value before increment/decrement; but by treating them consistently as strings? It would resolve the discrepancy with "5d9"; although not with "0xf9". -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Typed class constants
I initiated a conversation about the typed constants RFC back in March 2022: https://externals.io/message/117406 I had updated the RFC page, but it looks like the changes were reverted in December 2022. The updated version I was working on was: https://wiki.php.net/rfc/typed_class_constants?rev=1648644637 The updated RFC looks good, thanks for working on it. You may want to review the revised version I had worked on for implementation ideas, and review the previous conversations. The primary concept missing is declared but unassigned class constants, which must then be assigned a value in the concrete class. See the section on my revised version "Inheritance and variance". That'll be a question of if that can or should be included in this RFC or not. It provides the most value, allowing for inheritance from a parent class to ensure the value is set and typed in the concrete class. - Mark Niebergall On Tue, Jan 31, 2023 at 5:55 PM Ondřej Mirtes wrote: > I fully support this RFC. PHPStan added support for PHPDoc types in class > constants some time ago - it’s useful to rely on the same constant type > even in subclasses when accessing them via static:: or $object::. > > On Tue 31. 1. 2023 at 22:01, Máté Kocsis wrote: > > > Hi Everyone, > > > > A few years ago, Benas Seliuginas announced the "Typed constants" RFC ( > > https://externals.io/message/110755) which apparently had a > > positive reception overall. > > Unfortunately, there were some issues with the implementation (namely, > with > > the parser) > > so the RFC was stuck. > > > > A few weeks ago, I reached out to Benas whether he intended to resurrect > > the proposal, but > > due to time constraints, he couldn't, and was OK with me continuing it. > > With some help from > > Bob Weinand, I managed to overcome the implementation difficulties, and > > adapted it > > to the newly added type-related features. > > > > Please find the updated RFC here: > > https://wiki.php.net/rfc/typed_class_constants. > > > > Regards, > > Máté > > > -- > > Ondřej Mirtes >
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 20/01/2023 19:48, Kamil Tekiela wrote:
I don't think it's such a huge issue as you make it to be. The
documentation states this only as an alternative:
https://phpspreadsheet.readthedocs.io/en/latest/topics/accessing-cells/#looping-through-cells-using-indexes
It also mentions the pitfalls. I doubt many users would prefer that
"alternative" given that the recommended way is simpler and does the same
thing.
I also don't think that performance would come into play here. Any
difference would be insignificant.
I believe that the benefits of the deprecation outweigh any potential extra
work the developers may have.
I beg to differ. Having done a lot of work last year recommending the
deprecation of using of column indexes (1,2,3,etc) in favour of
addresses ('A', 'B', 'C', etc) to more closely match with Excel's
layout; and knowing how much the codebase uses alpha column incrementing
internally, I'm aware of how much an issue it is.
I'd prefer if developers using PhpSpreadsheet used the built-in
iterators, and Im in the middle of writing a post on the benefits of
doing just that; but "under the hood" alpha column names are used, not
numeric indexes'; so a lot of the "under the hood" code uses ++ and --
with row numbers and column addresses.
And replacing any PHP operator with a function call is always going to
be less performant.
The benefits of this deprecation seem to be making ++ and -- consistent
by making them little more than a syntactic sugar for numeric values
only; I'm afraid I don't see that as a benefit; but as a retrograde
step, and not the same as making ++ and -- consistent.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 20/01/2023 18:43, G. P. B. wrote: That's a strange hill to die on, most people would expect that those operators do indeed behave like Add1 and Sub1, and clearly you are not having any issue with making -- act like Sub1. It isn't so strange, when you consider that an OS library like PhpSpreadsheet with over 100million installs makes extensive use of alpha and numeric increment (not alphanumeric); and I dearly wish that PHP had implemented the decrement operator for alpha strings as well, because that would have allowed me to simplify the codebase even further; so I would prefer if -- acted like a decrement for alpha strings, and not simply as a Sub1 for numerics. The documentation page consistently uses the word Increment and Decrement, not Add 1 and Subtract 1. Developers who read the documentation should be aware of the Perl convention when dealing with alphabetic strings, and should expect that behaviour. Alphanumeric strings are certainly more problematic, less well documented, and less well understood, and I'll agree that they're inconsistent in their behaviour. Deprecating the Increment operator for strings will create extra work for me, will affect many of the users of my library, and I'm certain it will also have a performance impact on the library (replacing that operation with a more expensive function call for alpha increments, but still having the operation for numeric increments). So yes, I am willing to die on this hill because that deprecation will have a very direct and adverse affect on my work. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 18/01/2023 21:25, G. P. B. wrote: I would like to start the discussion on the Path to Saner Increment/Decrement operators RFC: https://wiki.php.net/rfc/saner-inc-dec-operators The goal of this RFC is to reduce language complexity by making $v++ behave like $v += 1 and $v-- behave like $v -= 1; If that is the goal, then I would agree with this RFC. However, changing the PERL string increment feature does not IMO fit into that goal, and it also a useful*feature*. On that base I would vote against this. And I suspect many others would as well. However, the ++ and -- are the "Increment" and "Decrement" operators, not the Add1 and Subtract1 operators; while they behave in that way when used with variables containing numeric values, they are special operators and not simply a syntactic sugar for +=1 and -=1. As long as their behaviour is consistent, and definition of what "Increment" and "Decrement" mean is clearly defined for different datatypes, then I feel that the PERL-style alpha string increment has enough valid use cases to justify itself. We might also discuss consistency of datatype changes when these operators are used. $a = PHP_INT_MAX; ++$a; or $a = '10'; ++$a; both change the datatype of $a; which isn't documented behaviour either. -- Mark Baker
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 18/01/2023 17:10, Craig Francis wrote: I agree that some of the incrementing behaviour can be a bit weird, and I would be happy to see those be deprecated/removed; but I worry that the A, B, ..., Z, AA, AB, etc is something that works well today, and is likely to be tricky to find/replace with a new function in all existing code. Replacing the use of an existing operator with a new function call, but only in certain circumstances (for alpha increments but not for numeric increments) would also be a pain; we'd have to examine every instance of ++ use to see what datatype it was being used on (SA tools won't necessarily help with that); and when looping over Excel rows and columns it would seem strange allowing the ++ operator for rows, but having to use a function call for columns when all previous code also used ++. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 18/01/2023 18:27, Kamil Tekiela wrote:
When I read the RFC I was a little sceptical about the deprecation of
string increment functionality. It's something I used in the past and I see
no easy upgrade path. However, after reading this thread and thinking it
over, I realize that deprecation is the right way to go. Someone said that
it's useful when working with Excel. Excel uses bijective base-26 system.
PHP does not. I cannot even explain what logic governs PHP string increment
functionality.
The logic is actually fairly straightforward if you consider breaking
the original string into blocks of alpha, numeric and non-alphameric
characters; so a string like 'C-37AZ99' would be broken into five blocks
of characters ('C', '-', '37', 'AZ' and '99').
Start with the rightmost block, but only if its alpha or numeric: the
process will never increment any block of characters that is non-alphameric.
Increment the current block.
If that increment would result in an overflow (extending the size of
that block) and there is another block to the "left" in the chain of
blocks, then that block is reset to its "base" value (discard the
overflow character), and the same process is repeated for incrementing
the next block in the chain.
The process terminates when there are no more blocks in the chain, or
when the process encounters a non-alphameric block.
The string is then "glued" back together again for the return.
In this regard, when a block is alpha characters, then the increment
behaviour matches "Excel's bijective base-26".
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 17/01/2023 17:28, Craig Francis wrote: I've seen this used a few times, e.g. starting with a numerical value (Passport number, NHS number, Social Security Number, Date of Birth 20230117), and the developer simply appends an incrementing letter on the end to get a unique reference; e.g. a person having multiple assessments... especially if it's more than 26 (A-Z), and you need to move to multiple letters, which `chr(90 + 1)` cannot help you with. Being able to increment alpha strings is incredibly useful when working with Excel spreadsheets (as I do on a daily basis), because the column Ids match this pattern; and I would hate to see this deprecated. Having to replicate that logic for traversing column Ids in userland code would be inconvenient (to say the least), would affect many of the users of my libraries, and would have a performance impact on my libraries. If anything, I'd rather like to see the decrement operator work with alpha strings as well for more consistency. I don't have the karma for a vote; but if I did then it would be a "No" for this alone, because I can see the problems that it will cause me and the users of my libraries. That said, I appreciate that incrementing some strings can be a bit unusual (e.g. "A9" to "B0", vs "A 9" to "A 0"). Agreed. While incrementing works in a very logical manner with mixed alphanumeric strings, it's not well documented behaviour, and most developers take a long time before they understand what it's actually doing. While there might be use cases for incrementing alphanumerics, I suspect that it would be better implemented in the business logic of an application, because the component parts of that string are likely to have business meaning; and also to provide better code readability. -- Mark Baker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] make install overwriting php.ini
Thanks for the reply Ben, once I get home I’ll send what I did exactly. Sent from my iPad > On Sep 17, 2022, at 11:42 AM, Ben Ramsey wrote: > > >> >>> On Sep 16, 2022, at 20:27, Mark Tomlin wrote: >>> >> To the release managers of PHP, please make sure that you do not overwrite >> the php.ini file. Making the php.ini.defaults file in the */usr/local/lib* >> is fine, but overwriting it when running *make install* is going to break >> some setups. This happened in both 8.2.0RC1 and now 8.2.0RC2. >> >> Please and thank you. > > > Mark, > > Running `make install` should not overwrite your system’s php.ini file. When > the release managers package a PHP release, we do not do anything that would > overwrite your system’s php.ini file. > > Can you share more information about how you’re installing PHP and what > behavior you are seeing? Be as detailed as you can. That’ll help us figure > out if there’s a bug somewhere. > > Cheers, > Ben >
[PHP-DEV] make install overwriting php.ini
To the release managers of PHP, please make sure that you do not overwrite the php.ini file. Making the php.ini.defaults file in the */usr/local/lib* is fine, but overwriting it when running *make install* is going to break some setups. This happened in both 8.2.0RC1 and now 8.2.0RC2. Please and thank you. -- Thank you for your time, Mark 'Dygear' Tomlin;
Re: [PHP-DEV] [RFC] Asymmetric visibility
On 08/08/2022 10:14, Marco Pivetta wrote: As for `readonly`, the reason we sometimes **cannot** use `readonly` is because current `clone` semantics can't work around `readonly` rules (discussed in the `readonly` RFC):https://3v4l.org/og8bn If we solved that, I think `private(set)` would become even more situational, if not completely unnecessary. I'm with Marco on this; the majority of use cases for asymetric properties could be resolved if internally cloned objects could update their readonly properties. And I also find the syntax looks odd, and not like any other aspects of PHP, not to mention the potential length of property definitions -- Mark Baker _ |. \ \-3 |_J_/ PHP | || | __ | || |m| |m| I LOVE PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC][Vote] New Curl URL API
On 05/07/2022 00:34, Pierrick Charron wrote: All recent discussions show that we are not even close to getting a consensus on how the new CurlUrl OO API should be done. After changing my mind 300 times in the last day, I decided to only propose the procedural implementation that stays consistent with other functions of the ext/curl to target 8.2. I know this is not the ideal scenario, but with 8.2 feature freeze in two weeks, this is I think the only approach that will not put us in a potentially bad/harmful situation for a better future with ext/curl. I'm voting no on this one based on the discussions from R11. The deadline being close is not a good enough reason to rush a change like this that will be difficult to unwind later. I agree with some of the other comments made that it would be preferable to come up with a more generic solution that can be used by multiple components rather than something specific to Curl. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] [Under Discussion] New Curl URL API
On 22/06/2022 05:38, Pierrick Charron wrote: Feel free to give any feedback, concern or support :-) This should preferably be namespaced. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
On 12/06/2022 19:21, Larry Garfield wrote: On Thu, Jun 9, 2022, at 11:34 AM, Larry Garfield wrote: A little data: I used Nikita's project analyzer on the top 1000 projects to get a rough sense of how long-closures are used now. All usual caveats apply about such survey data. I was specifically looking at how many `use` statements a closure typically had, and how many statements it typically had. Mainly, I am interested in how common "really long closures where the developer is likely to lose track of what is and isn't closed over" are. Total closures: 20052 Total used variables: 11534 Did many of those closures use "pass by reference" in the use clause, because that's one real differentiator between traditional closures and short lambdas. There's also the fact that use values are bound at the point where the closure is defined, not where it's called (if they even exist at all at that point), although that's probably more difficult to determine. -- Mark Baker _ |. \ \-3 |_J_/ PHP | || | __ | || |m| |m| I LOVE PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Adding new closing tag =?> for keeping trailing newline
On 05/06/2022 10:23, shinji igarashi wrote: I'd like to propose adding a new closing tag `=?>` to the language. PHP currently removes the newline character immediately following the closing tag `?>`. So we would have 4 possible combinations that developers could apply in their code, two existing open/close settings and two new combinations, the first you explain but also What should PHP do when it encounters this combination of opening/closing tags? -- Mark Baker _ |. \ \-3 |_J_/ PHP | || | __ | || |m| |m| I LOVE PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: NULL Coercion Consistency
On 28/05/2022 03:36, Craig Francis wrote: In this case, two of my clients are considering the cost of modifying their code (by adding a load of `?? ''` everywhere), and they would rather avoid that (time consuming, and makes their code more complicated). Alternatively, they may wish to define their own functions that do take null and then run a find / replace or rector rule to convert them over. I would still recommend ?? because it's the most future proof. We have passed two RFCs in recent months which will eliminate default-nulls in 2 of the 3 major variable sources in the engine (the remaining one being arrays), and that too may eventually find itself promoted. If it's a framework, I would suggest adding methods for explicitly getting a string that defaults to '' instead of null. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC][Under discussion] Create a global login system for php.net
On 28/05/2022 10:53, Aaron Junker wrote: When you have feedback to a specific point of the RFC, please use the corresponding number used in the RFC. To point 1, there was a time I was thinking about implementing a system ourselves (I was working on website prototypes at the time). That being said, as you identified creating our own system requires resources we don't have, and PHP is bad at infrastructure (lack of resources / specialists). For that reason I think the sensible thing to do would be to use Github. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Removal of ${} string interpolation in PHP 9
On 20/05/2022 10:05, Ilija Tovilo wrote: So unless there are concerns I will amend that in the RFC. Erroring it out makes sense to me. As we don't include any target version specification in PHP files, the safest bet it so prevent the silent change from potentially leaking through the introduction of a parser error. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Early feedback on encrypted session PR
On 18/05/2022 16:23, Craig Francis wrote: If the Session ID continued to work as the Identifier, but the client was given the Session ID and a Random Key (could be concatenated together for the cookie)... that means the Random Key would not be stored on the server, and could protect the session if there was a vulnerability on the server/website (e.g. attacker being able to see the directory listing of session files)... I'm not sure how much of a benefit that will actually provide, vs the risk of it going wrong (e.g. future PHP changing encryption algorithm). Personally I usually just throw the session key through a one-way hash so the original session ID never gets written to a backing store. I'm not sure why reversible encryption needs to take place? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Early feedback on encrypted session PR
On 17/05/2022 21:36, David CARLIER wrote: I wanted a more general but early feedback on the idea itself https://github.com/php/php-src/pull/3759 The same question that has already been asked on github: What is the motivation? What is it meant to achieve? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] NULL Coercion Consistency
On 08/05/2022 11:48, Jordan LeDoux wrote: This is not the case with null. If you use the unset() function on a variable for example, it will var_dump as null *and* it will pass an is_null() check *and* it will pass a $var === null *and* it will return false for an isset() check. Null loses these qualities if it is cast to *any* scalar. Fortunately the writing is on the wall for the undefined cases, but that doesn't take away from your argument. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] Undefined Property Error Promotion
On 21/04/2022 22:45, Mark Randall wrote: I have now opened voting on Undefined Property Error Promotion. https://wiki.php.net/rfc/undefined_property_error_promotion The vote has concluded. The RFC has been passed with 31 votes (86%) in favour, 5 against. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: PHP 8.2 Release Manager Selection
On 25/04/2022 12:51, Christoph M. Becker wrote: Please put your name forward here if you wish to be considered a candidate. An initial TODO page has been added to the wiki and contains provisional dates for GA and pre-releases[2]. I could potentially be interested in helping out with this, but I do have a question about it, mainly, why hasn't most of this been automated at this point? I was reading through the release process notes and am not seeing any obvious blocks on most of it that could not be accomplished via a suitable CI/CD pipeline. Is it just a matter of someone having time available to do it? The one thing which does make me ponder is would we need to assign a GPG key to the build process? I'd be happy to give some of my time later this year to further investigate this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Stricter implicit boolean coercions
On 26/04/2022 10:54, Andreas Leathley wrote: Any non-empty string (except "0") is converted to true and any non-zero integer or float is converted to true. If we could get rid of "0" being false, that alone would be a huge benefit for the language in the long run. I know why it exists, but I don't think it should. In fact it never should have existed in the first place. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion
On 22/04/2022 21:30, Rowan Tommins wrote: Do you not have even a little bit of hope that we could make that less confusing, since we're breaking everyone's old code anyway? I seem to remember we had a discussion years ago about deleting unset on properties, but it was being used for a very popular proxy manager to force them to be routed to __get. The rule that anything typed must be initialized, nullable or not, is clearish enough. You could special case nullable, but then it's an extra rule to learn beyond "typed = needs to be initialized". -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Property Error Promotion
On 22/04/2022 14:42, Rowan Tommins wrote: As with your previous RFC, I approve of this in principle, but am frustrated how little time has been spent considering the edge cases, such as the ones I mentioned here: https://externals.io/message/117487#117487 Accessing an unset property, which currently emits a warning, will instead throw an Error. If a property has already been written to via some mechanism, then the property exists and this RFC does not apply, no warning or error should be expected. It's a different responsibility to handle the guards against writing to one which has not been defined (AllowDynamicProperties RFC). Re: Case 4, an untyped property without its own initializer is effectively defaulted to null. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] Undefined Property Error Promotion
Internals, I have now opened voting on Undefined Property Error Promotion. https://wiki.php.net/rfc/undefined_property_error_promotion Voting ends 2022-05-05 Summary: This RFC seeks to prevent execution continuing if the user has accessed an undefined property without specifying that it was their intent to potentially do so. This RFC is designed to compliment the Undefined Variable Error Promotion, and Deprecate Dynamic Properties RFCs that have already passed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Property Error Promotion
On 06/04/2022 19:38, Larry Garfield wrote: On the last point, regarding stdClass, I think the question is whether we want it to be consistent with classed object properties (throw) or with associative arrays (warnings). stdClass is kind of an uncomfortable middle between those two. I'm not sure which is better to align with, although I almost never use stdClass and tell others to avoid it as well so it doesn't really matter to me. :-) My preference is to treat it like any other property, but I am open to hearing additional comments on this. I'm not sure how much conversation we can expect on this one, if it remains quiet I intend to open the vote in a week or so. As a tangent, R11 has had some comments made about a better method for indicating which property / array keys are expected to be missing, such as: $foo[?'maynotexist'] // returns null and emits no warning Down the line this might allow us to fix up arrays as well, but that's a question for a different RFC. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] NULL Coercion Consistency
On 11/04/2022 20:22, Craig Francis wrote: Keep in mind, if you're using `strict_types=1`, great, you're not affected (I'm not either)... however, I work with quite a few developers, and it's causing them a lot of problems, and their current approach is to either disable the deprecation warnings, or to stay with 8.0, simply because they do not have the time to make the changes... I will note that one team has been trying to update their code base, it's about 6 months later, and they still keep adding `strval()` to silence these deprecation warnings (yeah, I know, not good, but it's the easy solution). This doesn't only apply to end user developers, but also to library and toolchain developers who need to maintain code covering a range of PHP versions, and who also need to make these trade-offs. It's those maintainers that have to deal with the impact of this type of change, whether needing to apply changes to their libraries to "suppress" the deprecation notice; or dealing with end-user developers raising the same issues time and again about it because they don't want to see deprecation notices appearing in their logs. Even though this was only a deprecation, most end-user developers don't recognise that difference from logged errors when using libraries, so the impact is felt most heavily by library and toolchain maintainers. This 8.1 deprecation was the one that created the most work, and the most stress for me; and even with an average of 85% code coverage with tests, I'm still not certain that I've resolved every instance using the dirty `$x ?? ''` approach when calling PHP core functions. In many ways, readying code for the 8.1 release because of this deprecation was more painful and time consuming than for the 8.0 release. With all the new deprecations being added for 8.2, I'm looking forward to it even less. That's also why I wish there was a better risk assessment made for every deprecation RFC; becase all too often there's little or none; and why I get frustrated whenever a question is raised about an RFC, and the person raising these concerns is too often shouted down for raising "a storm in a teacup". -- Mark Baker _ |. \ \-3 |_J_/ PHP | || | __ | || |m| |m| I LOVE PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Property Error Promotion
On 06/04/2022 17:34, Marco Pivetta wrote: Perhaps worth mentioning that magic methods keep working? Good call. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Undefined Property Error Promotion
Internals, Part 2 of the undefined behaviour improvements, this time focusing on properties. https://wiki.php.net/rfc/undefined_property_error_promotion This RFC draws heavily from the just passed undefined variables error promotion RFC, and is intended to compliment both it, and the 8.2 Deprecate Dynamic Properties RFC. The arguments in favour are the same as the last one, reading things which don't exist will often lead to the program entering an unintended state, and is likely the result of a programming error. There is a difference though that we do explicitly provide an object that is designed to be dynamic, and that is stdClass which is the typical output from json_decode and array to object casts. I would expect we might want to discuss special-casing the accessing of properties on stdClass and leave them as a warning. However, I personally think that for the sake of consistency we should make undefined properties throw across the board, including stdClass. We already have fully backwards compatible mechanisms built into the language (isset, empty, null coalesce, property_exists) to safely handle cases of the property not being defined, even on objects that do not have a fixed structure. I was originally going to include a section for discussion about potentially using AllowDynamicProperties to pull double duty, allowing reads without an error as well, but I do not believe that would be in the best interests of the language, and so removed it. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Typed constants revisited
Guilliam,
On Wed, Mar 30, 2022 at 7:50 AM Guilliam Xavier
wrote:
> Hi Mark,
>
> I have updated the RFC https://wiki.php.net/rfc/typed_class_constants with
>>>> more details and examples from this thread, and updated the RFC status
>>>> to
>>>> Under Discussion. Hopefully the updated RFC helps answer questions and
>>>> clarifies what the proposal includes.
>>>>
>>>
> Thanks (I assume that you talked with the original author) -- not sure if
> you should have started a new thread with the "[RFC]" tag in the subject?
>
I will address the issues from you and Alex in the RFC page, then start a
new thread with "[RFC]" since you are correct this has moved past
initial testing-the-waters and is now into the discussion phase about the
RFC. I reached out multiple times to the original author but have not
received a response. I did leave Benas as an author to give him credit for
the work he did.
>
>
>> I think you should also update the "Supported types" section.
>>> Starting with enums, constants can also be objects. Once a good
>>> technical solution is found, any object would be supported probably
>>> https://wiki.php.net/rfc/new_in_initializers#future_scope
>>> I think that only void, never and callable types should not be
>>> supported, just like on properties.
>>>
>>
>> I have updated the "Supported types" to list out all types that are
>> supported and which types are not supported.
>>
>
> A few comments, by subsection:
>
> - **Supported types**: This corresponds to the types currently allowed
> for const values (as well as unions thereof) except it [still] doesn't
> mention enums (which internally are classes implementing the `UnitEnum`
> interface, and whose values are ultimately of `object` type) although
> currently allowed. It also doesn't mention `mixed` (used later in examples).
> - **Strict and coercive typing modes**: I didn't understand it on first
> read; I had to read the later "Constant values" section and compare both
> with
> https://wiki.php.net/rfc/typed_properties_v2#strict_and_coercive_typing_modes
> and https://wiki.php.net/rfc/typed_properties_v2#default_values
> - **Inheritance and variance**: Several occurrences of "Class constants"
> should probably be "*Typed* class constants". Also, I still think that
> `protected bool $isExtinct` is *not* a good parallel to `public const bool
> CAN_FLY` (see my previous message).
> - **Constant values**: You should probably remove the `iterable` example
> now [and maybe add an `enum` one].
>
Thanks for the input, I'll work on addressing those.
>
>
>> Constants cannot be objects since objects are mutable, so typed constants
>> will not be allowed to be an enum (which is technically an object). A typed
>> constant _may_ be an enum value though, so the following example will be
>> valid:
>>
>> ```
>> enum Fruit
>> {
>> case Apple;
>> case Banana;
>> }
>>
>> class Colors
>> {
>> protected const string RED = Fruit::Apple;
>> protected const string YELLOW = Fruit::Banana;
>> }
>> ```
>>
>
> This is incorrect, `Fruit::Apple` is of type `Fruit` (ultimately
> `object`), not `string`. But it is *not* mutable, and *is* allowed as a
> const value currently.
>
Yes, Alex also identified this issue in my examples, I will correct that
and include enum examples in an updated RFC. I will do that before starting
an "[RFC]" thread.
>
> Besides, I realized that the RFC is [only] for *class* constants; what
> about *namespaced (and global)* constants?
>
Ah yes, I hadn't considered expanding this RFC to namespaced and global
constants. Let me mull over implementation syntax for those and include
them in the RFC. My initial reaction is to not include those in this RFC,
keeping the scope to just class constants. If there is value in typing
namespaced and global constants, then another RFC could add those.
Once I have all these new issues figured out and the RFC updated, I'll
start that new thread.
>
> Regards,
>
> --
> Guilliam Xavier
>
Re: [PHP-DEV] Typed constants revisited
Alex,
On Wed, Mar 30, 2022 at 7:47 AM Alexandru Pătrănescu
wrote:
> Hey Mark,
>
> On Wed, Mar 30, 2022 at 4:01 PM Mark Niebergall
> wrote:
>
>> Alex,
>>
>> On Tue, Mar 29, 2022 at 10:35 PM Alexandru Pătrănescu
>> wrote:
>>
>>> Hey Mark,
>>>
>>>
>>> On Wed, Mar 30, 2022 at 6:03 AM Mark Niebergall
>>> wrote:
>>>
>>>>
>>>> I have updated the RFC https://wiki.php.net/rfc/typed_class_constants
>>>> with
>>>> more details and examples from this thread, and updated the RFC status
>>>> to
>>>> Under Discussion. Hopefully the updated RFC helps answer questions and
>>>> clarifies what the proposal includes.
>>>>
>>>
>>> Thanks for the RFC and the drive here.
>>> I personally see the benefit and I think it would be a nice addition.
>>>
>>> I think you should also update the "Supported types" section.
>>> Starting with enums, constants can also be objects. Once a good
>>> technical solution is found, any object would be supported probably
>>> https://wiki.php.net/rfc/new_in_initializers#future_scope
>>> I think that only void, never and callable types should not be
>>> supported, just like on properties.
>>>
>>>
>> I have updated the "Supported types" to list out all types that are
>> supported and which types are not supported.
>>
>> Constants cannot be objects since objects are mutable, so typed constants
>> will not be allowed to be an enum (which is technically an object). A typed
>> constant _may_ be an enum value though, so the following example will be
>> valid:
>>
>> ```
>> enum Fruit
>> {
>> case Apple;
>> case Banana;
>> }
>>
>> class Colors
>> {
>> protected const string RED = Fruit::Apple;
>> protected const string YELLOW = Fruit::Banana;
>> }
>> ```
>>
>
> Actually, Fruit::Apple is an enum instance and that is an object that is
> of Fruit enum type (Fruit class).
> You can check this as it's already possible in PHP 8.1, even if it's not
> yet possible to have them with type: https://3v4l.org/f4WIC
>
> What you are referring to as enum value is actually a backed value for an
> enum instance.
> If you would define the enum as
> ```
> enum Fruit: string
> {
> case Apple = 'apple';
> case Banana = 'banana';
> }
> ```
> You could obtain the value with Fruit::Apple->value. But I'm not
> referring to this.
>
> So going back to the topic I mentioned, a constant can right now be an
> object.
> It can be only an enum instance for now but I believe that in the near
> future we will be able to have any object there.
>
Ah yes, you are correct, my mistake. I will need to make some more updates
to the RFC page to address that.
>
> Also, self and parent would make sense for valid typed constants, just
> like they do work on properties.
>
I'll add examples and an item about this as well.
>
> Regards,
> Alex
>
>
>>
>>>
>>>> Of note is the "Inheritance and variance" section, which details uses
>>>> with
>>>> abstracts and interfaces, plus the "Constant values" section which
>>>> includes
>>>> details about errors.
>>>>
>>>>
>>>> >
>>>> > --
>>>> > Guilliam Xavier
>>>> >
>>>>
>>>
>>> Thanks,
>>> Alex
>>>
>>
Re: [PHP-DEV] Typed constants revisited
Alex,
On Tue, Mar 29, 2022 at 10:35 PM Alexandru Pătrănescu
wrote:
> Hey Mark,
>
>
> On Wed, Mar 30, 2022 at 6:03 AM Mark Niebergall
> wrote:
>
>>
>> I have updated the RFC https://wiki.php.net/rfc/typed_class_constants
>> with
>> more details and examples from this thread, and updated the RFC status to
>> Under Discussion. Hopefully the updated RFC helps answer questions and
>> clarifies what the proposal includes.
>>
>
> Thanks for the RFC and the drive here.
> I personally see the benefit and I think it would be a nice addition.
>
> I think you should also update the "Supported types" section.
> Starting with enums, constants can also be objects. Once a good technical
> solution is found, any object would be supported probably
> https://wiki.php.net/rfc/new_in_initializers#future_scope
> I think that only void, never and callable types should not be supported,
> just like on properties.
>
>
I have updated the "Supported types" to list out all types that are
supported and which types are not supported.
Constants cannot be objects since objects are mutable, so typed constants
will not be allowed to be an enum (which is technically an object). A typed
constant _may_ be an enum value though, so the following example will be
valid:
```
enum Fruit
{
case Apple;
case Banana;
}
class Colors
{
protected const string RED = Fruit::Apple;
protected const string YELLOW = Fruit::Banana;
}
```
>
>> Of note is the "Inheritance and variance" section, which details uses with
>> abstracts and interfaces, plus the "Constant values" section which
>> includes
>> details about errors.
>>
>>
>> >
>> > --
>> > Guilliam Xavier
>> >
>>
>
> Thanks,
> Alex
>
Re: [PHP-DEV] Typed constants revisited
On Mon, Mar 28, 2022 at 6:54 AM Guilliam Xavier
wrote:
> Constants are not abstract in an interface - they must be assigned a
>> value. Only classes and methods can be abstract. Within an abstract class
>> it is not valid to have an abstract property. Properties can be defined
>> `protected int $id;` and optionally assigned a value `protected int $id =
>> 5;`, but cannot be `abstract protected int $id;`.
>>
>
> That's the *current* state of the language indeed, but to me, [part of]
> your proposal looks like introducing "abstract constants"... Maybe I'm
> misunderstanding?
>
>
>> So to me it makes more sense to have constants follow the same syntax as
>> properties `public const bool CAN_FLY;` without the `abstract` keyword.
>>
>> An example:
>>
>> ```
>> abstract class Bird
>> {
>> public const bool CAN_FLY;
>> protected bool $isExtinct;
>> ```
>>
>> This allows for similar behavior, similar requirements, and similar
>> syntax - consistency ftw!
>>
>
> For similarity/consistency, the `$isExtinct` property should probably be
> [`public` and] `static` (actually `readonly` too, but cannot be both).
>
> But, again, we can also see some similarity with `static` *methods*, e.g.:
>
> ```
> abstract class Bird
> {
> abstract public const bool CAN_FLY;
> abstract public static function isExtinct(): bool;
> }
> class Dove extends Bird
> {
> // NOTE: the following two lines are required (in the class definition)
> public const bool CAN_FLY = true;
> public function static isExtinct(): bool { return false; }
> }
> // var_dump(Dove::CAN_FLY);
> // var_dump(Dove::isExtinct());
> ```
>
> Besides, an uninitialized property must be initialized before first read,
> but is *not* required to be overridden/redefined (with a value) in a child
> class; so in this example (still hypothetical):
>
> ```
> abstract class Bird
> {
> public const bool CAN_FLY;
> public static bool $isExtinct;
> }
> class Dodo extends Bird
> {
> // NOTE: the following two lines are commented out
> // public const bool CAN_FLY = false;
> // public static bool $isExtinct = true;
> }
> var_dump(Dodo::CAN_FLY);
> var_dump(Dodo::$isExtinct);
> ```
>
> where would the [missing value for constant] error be: on the definition
> of class Dodo (like for an unimplemented abstract method), or only when
> trying to access Dodo::CAN_FLY (like for an uninitialized property)?
>
>
>>
>> There seems to be interest and good use cases (thanks Sara for the good
>> practical example!). At this point I'm going to work on a new RFC with all
>> the details and feedback from this discussion.
>>
>>
>
> Thanks & good luck! =)
>
I have updated the RFC https://wiki.php.net/rfc/typed_class_constants with
more details and examples from this thread, and updated the RFC status to
Under Discussion. Hopefully the updated RFC helps answer questions and
clarifies what the proposal includes.
Of note is the "Inheritance and variance" section, which details uses with
abstracts and interfaces, plus the "Constant values" section which includes
details about errors.
>
> --
> Guilliam Xavier
>
[PHP-DEV] Re: [VOTE] Undefined Variable Error Promotion
On 14/03/2022 17:18, Mark Randall wrote: I have started the vote for promoting undefined variable access to throw an Error exception. The vote will run for 2 weeks until March 28th 2022. https://wiki.php.net/rfc/undefined_variable_error_promotion The RFC has passed with 33 votes (80%) in favour and 8 against. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Typed constants revisited
On Fri, Mar 25, 2022 at 10:55 AM Guilliam Xavier
wrote:
> I intentionally left `abstract` out of `public const bool CAN_FLY;` in the
>> `abstract class` for consistency with the implementation with `interface`,
>> which would also have to be `public const bool CAN_FLY;`. Currently
>> `abstract` is only used in front of methods `abstract function doThing():
>> bool;`. Open to discussion - which way is ideal or preferred? That could be
>> included as a subset of an RFC vote if a consensus during discussion isn't
>> reached.
>>
>
> I understand, but note that methods are implicitly abstract in an
> interface, but it must be explicit in an abstract class; and since I see
> the proposed feature mainly as a "replacement" for abstract static methods
> [whose all implementations just return a literal value]... (anyway, not
> super important)
>
Constants are not abstract in an interface - they must be assigned a value.
Only classes and methods can be abstract. Within an abstract class it is
not valid to have an abstract property. Properties can be defined
`protected int $id;` and optionally assigned a value `protected int $id =
5;`, but cannot be `abstract protected int $id;`. So to me it makes more
sense to have constants follow the same syntax as properties `public const
bool CAN_FLY;` without the `abstract` keyword.
An example:
```
abstract class Bird
{
public const bool CAN_FLY;
protected bool $isExtinct;
```
This allows for similar behavior, similar requirements, and similar syntax
- consistency ftw!
There seems to be interest and good use cases (thanks Sara for the good
practical example!). At this point I'm going to work on a new RFC with all
the details and feedback from this discussion.
[PHP-DEV] Requesting wiki, RFC karma
Hello All, I would like to request wiki edit privileges and RFC karma. Quick intro - I co-organize the Utah PHP Usergoup, speak at PHP and tech conferences, volunteer for cyber security exam certification development, work on a vulnerability management platform with PHP, and have been developing in PHP for ~17 years. Plans - I'm picking up the typed constants RFC where it was left off, planning to create a new RFC for this go around. I have a few other future ideas I've also been tinkering with and plan to create several other RFCs in the future. Username: mbniebergall Thanks, Mark Niebergall
Re: [PHP-DEV] Typed constants revisited
Guilliam,
On Fri, Mar 25, 2022 at 6:35 AM Guilliam Xavier
wrote:
> Hi Mark,
>
> On Wed, Mar 23, 2022 at 11:55 PM Mark Niebergall
> wrote:
>
>> (...)
>>
>> Another example I often see in my projects could be used with a similar
>> example:
>>
>> ```
>> abstract class Bird
>> {
>> public const bool CAN_FLY;
>> public const string FAMILY;
>> public function canFly(): bool
>> {
>> return self::CAN_FLY;
>> }
>> }
>> final class EmperorPenguin extends Bird
>> {
>> public const bool CAN_FLY = false;
>> public const string FAMILY = 'penguin';
>> }
>> ```
>>
>
> I had this "need" too (and used abstract static methods where the
> implementations just return a literal value...).
>
> Just 2 remarks: in abstract class Bird, shouldn't it be:
> - "*abstract* public const bool CAN_FLY;" (and same for FAMILY)
> - "return *static*::CAN_FLY;"
> ?
>
I intentionally left `abstract` out of `public const bool CAN_FLY;` in the
`abstract class` for consistency with the implementation with `interface`,
which would also have to be `public const bool CAN_FLY;`. Currently
`abstract` is only used in front of methods `abstract function doThing():
bool;`. Open to discussion - which way is ideal or preferred? That could be
included as a subset of an RFC vote if a consensus during discussion isn't
reached.
Good correction, yes, `return static::CAN_FLY;` in that example in the
concrete child class.
>
> Regards,
>
> --
> Guilliam Xavier
>
Re: [PHP-DEV] Typed constants revisited
On Thu, Mar 24, 2022 at 1:00 PM Rowan Tommins
wrote:
> On 23/03/2022 18:54, Mark Niebergall wrote:
> > The next phase of work with different RFC would take
> > this further with const inheritance, where const type must match.
>
>
> I'm not sure it makes much sense to split this into two RFCs, and as far
> as I can see, the previous RFC included both features:
>
> > Class constants are covariant. This means that the type of a class
> constant is not allowed to be widen during inheritance.
>
>
> Or is there something more you mean by "const inheritance", which isn't
> covered by the RFC's examples?
>
Agreed, the more discussion that is going on, the more I'm leaning towards
to see this implemented in a single RFC. The true value comes with the full
feature set.
Correct the original RFC discusses some inheritance, but didn't expand it
out the way I'm thinking. It only details ensuring the concrete class has a
matching type. I'm proposing additionally allowing blank values to be set
by the concrete class.
Existing draft RFC (https://wiki.php.net/rfc/typed_class_constants):
```
class Test {
private const int A = 1;
public const mixed B = 1;
public const int C = 1;
}
class Test2 extends Test {
// this is legal (because Test::A is private)
public const string A = 'a';
// this is legal
public const int B = 0;
// this is illegal
public const mixed C = 0;
}
```
What I'm proposing would further allow const without values in abstracts
and interfaces, which require concrete classes to have a value:
```
abstract class Test
{
private const int A = 1;
public const mixed B = 1;
public const int C = 1;
// no value set, this is legal, concrete classes must set value
public const int D;
}
interface TestInterface
{
// no value set, this is legal
public const string NAME;
}
class Test2 extends Test implements TestInterface
{
// this is legal (because Test::A is private)
public const string A = 'a';
// this is legal
public const int B = 0;
// these are required due to inheritance
public const int D = 5;
public const string NAME = 'EmperorPenguin';
// this is illegal
public const mixed C = 0;
}
```
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Typed constants revisited
Pierre, On Thu, Mar 24, 2022 at 9:20 AM Pierre wrote: > Le 24/03/2022 à 16:06, Mark Niebergall a écrit : > > So you are correct, the const value does have a value that has a type, > but > > there is no way to enforce which type the value is or to use const with > > inheritance, which is part of the bigger picture here. > > That was exactly my point: the type could simply implicitely be the one > of the original value. > > Then the engine just has to use the existing covariance/contravariance > rules for type checks based upon the guessed value type. This would fix > the type safety issue you are referring to. > I'd rather not use the "guessed value type" in code, that tends to lead to bugs: guessing = bugs. Explicitly declaring the type avoids the pitfalls of guessing and ensures code predictability. It also comes with added benefits, including self-documenting code, defined inheritance requirements (the way you describe would have BC breakage), and (for some IDEs) type hinting. Of note, many other languages already have typed constants. Yes this is the "everyone else is doing it" argument, but they had their valid reasons. Some are strong typed languages, others are not. See: - Go: https://go.dev/blog/constants - HVVM: https://docs.hhvm.com/hack/classes/type-constants - C: https://fresh2refresh.com/c-programming/c-constants/ - C++: https://en.cppreference.com/w/c/language/const - C#: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/const > > -- > > Regards > >
Re: [PHP-DEV] Typed constants revisited
Pierre, On Thu, Mar 24, 2022 at 1:04 AM Pierre wrote: > Le 23/03/2022 à 23:10, Larry Garfield a écrit : > > Is there a benefit to it other than "well everything else has types now, > so..."? Even if it's esoteric, like in reflection-based meta programming? > (I've been dabbling too much in that lately. :-) ) "Everything else does" > isn't a compelling argument for me, but there may be others I'm not > thinking of. > > > > --Larry Garfield > > > Hello, > > Well I was thinking myself that const being well... constant, and so > always defined, type could be determined at compile time without the > need to express it in a verbose way. > > PHP doesn't do any static type inference, but in this case, it could be > done almost for free, am I wrong ? If it was determined at compile time, > then the type checking on overrides would only be trivial, using the > parent occurrence value inferred type. My point is that there's no need > to express the type of a value, the value has already has a type. > As a developer, I don't *always* trust other developers implementing my code. Referring back to the Bird and EmperorPenguin example, the expected type for `public const bool CAN_FLY;` example MUST be a bool. If it isn't typed, another developer _could_ incorrectly set `CAN_FLY = 1;` or `CAN_FLY = 'true';` or even `CAN_FLY = 'Y';`. With class constants typed, they would get an error if setting it to anything other than a bool `CAN_FLY = true;` or `CAN_FLY = false;`. This further proliferates into sending the value of `CAN_FLY` into a typed argument like `protected function determineModeOfTransport(bool $canFly)` - if the constant is set incorrectly as a string or integer then more errors can occur. Typing class constants could also help static code analyzers more easily determine if there are bugs with unexpected value types being used in code. Instead of determining the value of the constant, the type of the constant could be used instead, providing a cleaner tokenized parsing. So you are correct, the const value does have a value that has a type, but there is no way to enforce which type the value is or to use const with inheritance, which is part of the bigger picture here. > > Regards, > > -- > > Pierre > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] Typed constants revisited
On Wed, Mar 23, 2022 at 4:10 PM Larry Garfield
wrote:
> On Wed, Mar 23, 2022, at 1:54 PM, Mark Niebergall wrote:
> > Hello All,
> >
> > In June 2020, Benas Seliuginas emailed this list (
> > https://externals.io/message/110755#110755) to gauge interest in typed
> > constants. An RFC (https://wiki.php.net/rfc/typed_class_constants) was
> > started and had an accompanying PR (
> https://github.com/php/php-src/pull/5815).
> > At the time, Nikita Popov supported it for overall language consistency,
> > and Sebastian Bergmann +1'd it for overall language consistency as well.
> > The PR has since been closed without being merged, and the idea hasn't
> > progressed since.
> >
> > I'd like to revisit the concept, gauge current interest, and pick the
> > concept and work back up. Any more discussion items for or against the
> idea?
> >
> > I'm willing to do the work to pick it up where it was left off and get an
> > RFC proposed through the normal process, and a working PR. This is my
> first
> > foray into the PHP RFC process, and C code is not my forte, but I'll take
> > it on. If anyone would be willing to pair/mentor/co-author with me,
> please
> > let me know. Either way, I'll plan to work on it.
> >
> > This is the first of several concepts I have been tinkering with and
> seeing
> > practical uses for. The next phase of work with different RFC would take
> > this further with const inheritance, where const type must match.
> >
> > - Mark
>
> Is there a benefit to it other than "well everything else has types now,
> so..."? Even if it's esoteric, like in reflection-based meta programming?
> (I've been dabbling too much in that lately. :-) ) "Everything else does"
> isn't a compelling argument for me, but there may be others I'm not
> thinking of.
>
> --Larry Garfield
>
Larry and Internals,
To the benefits!
On its own, typing class constants does help align them with other things
like typed class properties, typed arguments, and method return types.
There will come additional benefits though, and this would be phase 1.
Phase 2 would be to introduce typed constants to be set by extending or
implementing classes. Combining the two features would lead to better
defined and usable class constants.
For example, an interface could be:
```
interface DbTable
{
public const string TABLE_NAME;
}
```
Which would then be implemented as:
```
class UserTable implements DbTable
{
public const string TABLE_NAME = 'user';
}
```
Thus ensuring `TABLE_NAME` is always set, and always returns a `string`
type. See https://docs.laminas.dev/laminas-db/table-gateway/ for a
real-world framework example where this feature _could_ be used.
Another example I often see in my projects could be used with a similar
example:
```
abstract class Bird
{
public const bool CAN_FLY;
public const string FAMILY;
public function canFly(): bool
{
return self::CAN_FLY;
}
}
final class EmperorPenguin extends Bird
{
public const bool CAN_FLY = false;
public const string FAMILY = 'penguin';
}
```
In this case, one could instead use typed class properties, but it feels
improper since the values are static and unchanging. Immutability is a work
around to this when implemented properly. This would simplify the solution
while ensuring values remain unchanged.
- Mark
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
[PHP-DEV] Typed constants revisited
Hello All, In June 2020, Benas Seliuginas emailed this list ( https://externals.io/message/110755#110755) to gauge interest in typed constants. An RFC (https://wiki.php.net/rfc/typed_class_constants) was started and had an accompanying PR (https://github.com/php/php-src/pull/5815). At the time, Nikita Popov supported it for overall language consistency, and Sebastian Bergmann +1'd it for overall language consistency as well. The PR has since been closed without being merged, and the idea hasn't progressed since. I'd like to revisit the concept, gauge current interest, and pick the concept and work back up. Any more discussion items for or against the idea? I'm willing to do the work to pick it up where it was left off and get an RFC proposed through the normal process, and a working PR. This is my first foray into the PHP RFC process, and C code is not my forte, but I'll take it on. If anyone would be willing to pair/mentor/co-author with me, please let me know. Either way, I'll plan to work on it. This is the first of several concepts I have been tinkering with and seeing practical uses for. The next phase of work with different RFC would take this further with const inheritance, where const type must match. - Mark
Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion
On 16/03/2022 09:17, Christian Schneider wrote: Maybe we should ask ourselves the question: Why would the entire package be blocked? Just because it is too big or maybe there *are* subtleties which have not been properly resolved? It's politics and the practicalities of getting things done. An all-or-nothing approach will inevitably end up with nothing, because those who are opposed on principle need only rally around attacking the weakest element, without the need to address any of the other parts which might individually be much stronger. That's not to say that the weakest elements shouldn't be debated, they should. But we shouldn't sabotage ourselves, and bring about a state of permanent project paralysis, by mandating that semi-related weaker changes are bundled with stronger ones and must be voted on as a whole. It would just open the door to the constant use of a poison pill argument. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion
On 15/03/2022 23:02, Patrick ALLAERT wrote: I am not against the fact this warning becomes an error per se. I am just not very fan of cherry-picking an individual kind of problem (read: notice/warning/error/...) and changing it without a more global frame. I think we should try to hit all of them, ideally in time for PHP 9. That was the premise behind: https://externals.io/message/116918 It will likely take several RFCs until we've got it in the state we want it, some of those are more contentious than others (such as undefined array indexes). I think undefined property access should throw too, and will likely have supermajority support, but let's do it in a separate RFC. What I don't think we want is the entire package being blocked because a particular item (i.e. array keys) is contentious. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion
On 15/03/2022 19:32, Sara Golemon wrote: What I'm hearing is that we also need an RFC for promoting 'Undefined index...' warnings to Errors as well. We do. If it would pass or not is another matter, it would need someone braver than I to take it up. I think there's some other engine stragglers, e.g. foreach must be type array|object comes to mind, that should really be an exception, maybe array to string conversion too. Who knows, maybe PHP 9 can be the version that removes remove *all* warnings from the zend engine. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation
On 12/03/2022 15:23, Ilija Tovilo wrote: You're absolutely right. I will attempt to gather some numbers. For option 3, I also think "not widely used" is just plain wrong. As for option 4, I'm fairly confident it only exists by accident 95% of the time. Like Andreas, this is my biggest concern with the proposal: the lack of actual figures for how many libraries will be affected b the change. We've seen a lot of deprecations over the last year, and they always create some degree of pain for library/toolchain maintainers. While typically dismissed as "it's just a deprecation notice", and being accused of creating a "storm in a tea cup" whenever we raise questions, library maintainers are the ones who have to deal with the additional work when end users raise issues against their repos becase of all the notices they're nw seeing in their logs; who already have a lot of work preparing for each new release; who are expected to have fully eliminated any deprecations from their repos (or their dependencies) on or before the GA release date. How much extra work and/or stress is it going to give those who maintain the PHP ecosystem? From the preparation work for the 8.0 release, there has barely been breathing space over the last two years; dealing with null arguments passed to internal functions, and other (not always docmented) changes, those libraries/tools take a lot of work to maintain. And with so many deprecations going into this release, I would like to see some risk assessment undertaken on the affect that each deprecation RFC will have, with some real figures for the number of repositories that require work to prepare them for the release. -- Mark Baker _ |. \ \-3 |_J_/ PHP | || | __ | || |m| |m| I LOVE PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [VOTE] Undefined Variable Error Promotion
I have started the vote for promoting undefined variable access to throw an Error exception. The vote will run for 2 weeks until March 28th 2022. https://wiki.php.net/rfc/undefined_variable_error_promotion Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Question: What are requirements for having (new/old) functionswithin PHP core? :)
On 07/03/2022 12:56, Thomas Krüger wrote: Or if it has nothing to do with performance, why not including everything from PECL into PHP core, so PHP could offer out-of-the-box more and more features for developers? PECL packages get to maintain their own release schedule, unlike PHP which follows a fixed cycle. PECL packages have their own permissions, unlike PHP which only allows a narrow group to merge code into it. The PHP core team does not have the knowledge or time to maintain every PECL package, or even a large number of them. Things distributed in Core should be produced and tested to the same standard as the engine itself. Certain PECL packages conflict such as if they were forked. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing NULL for some internal functions
On 01/03/2022 00:36, Craig Francis wrote: And because I'm back to tired pissed-off sarcasm masking depression (why bother spending days on a solution that works for everyone when we can make a hostile/elitist environment/language)... maybe we could simply suggest that everyone affected by this should use strval() for everything? People aren't giving you the responses you want, because you haven't yet made an argument to convince everyone that your proposed solution is better than the existing ones, which are to use the language's existing tools to provide a sensible string default where one is required. You see a problem, but rather than trying to fix the underlying cause, you're proposing making changes at other layers to accommodate the side effects of the original problem. That is practically the definition of a hack. Except rather than a short term fix, you're proposing to make it a permanent part of PHP. That goes against what many of us would consider in the best interests of PHP and its users in the long term, and yes, we acknowledge that getting to that point will first require some short term pain for those who have historically been overly lax with their coding standards. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing NULL for some internal functions
On 28/02/2022 01:46, Craig Francis wrote: Personally I think `strict_types=1` is fine for my code, but I would never want to force that style on everyone, because doing so would be fairly hostile for a language that's popular and well known for being easy to use/learn. Magically coercing things and hiding things under the hood is useful for the first 10 minutes of learning. After that it just becomes a hindrance difficult because you have to know all of the secret rules about type juggling. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Proposal for RFC to remove undefined arrayindexwarning when used ina ternary
On 27/02/2022 09:12, Robert Landers wrote: I'd also venture that this warning has caused more harm than good, in that writing "$var['something'] ?? null" is second nature when writing new code, even if there is practically no chance for a non-existent key. Using null coalesce should only be used when you know you have the possibility of a missing key. For everything else you've probably entered an unexpected state and should display a warning (that should ideally be picked up by an exception handler and convert it to an exception). When handling external data it is usually a good idea to use a validation step before using it, such as JSON schema. An even better idea is to parse it into a specific type, rather than just validating it, at which point you're going to be using a lot of isset, null coalesces, array_key_exists, property_exists etc anyway and sucking in some default other than null is almost always the wrong thing to do. As to your final point: PHP internals voted by a supermajority to raise this from a notice to a warning in PHP 8, it seems unlikely that 33% of people are now going to change their mind and vote for the opposite. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Proposal for RFC to remove undefined array indexwarning when used ina ternary
On 26/02/2022 22:34, Robert Landers wrote:
This is not semantically the same though. A $_POST of a form, for example,
will usually contain an empty value if the form input was empty, but
missing if the form control wasn't in the form (maybe the form control is
injected via Javascript, or conditionally output by the script).
PHP is a general purpose language, the behaviour you're asking for is
specific to one use case and may be of detriment to others, without
offering significant benefit in exchange.
I suggest you write yourself a function that performs the operations for
you. This may also be a good opportunity to move away from directly
accessing the superglobals in userland code.
$form->get('foo', 'defaultgoeshere');
Performance concerns would be so so small they would be practically
undetectable in the context of a real request.
Also, this:
$name = empty($_POST['name'] ?? 'Default Name') ?: 'Default Name';
Should be:
$name = ($_POST['name'] ?? null) ?: 'Default Name')
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Proposal for RFC to remove undefined array index warning when used ina ternary
On 26/02/2022 09:09, Robert Landers wrote: I'd like to propose and implement an RFC that would consider dropping the warning if and only if array access is the only test in ternary and short ternary (?:) operations but first I'd like to start a discussion to see if it is worth pursuing. I'd like to target PHP 8.2 or 8.3. The warning comes from the array key being missing, not from being empty. There are many values which are empty which do not emit the warning. If you want to provide a default should the array key be missing you want null coalesce. $x = $array['foo'] ?? 'somethingelse'; -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 24/02/2022 02:31, Bob Weinand wrote: However, should your RFC pass, it is not possible to say "hey, I generally consider this a low impact class of errors, please try to continue". This is correct. As the custodians of the language, it is our responsibility to decide what the engine considers low / high impact and act accordingly. In some cases users get the choice, but in most cases we make the choice for them. We have internals and the voting system precisely for this reason, to have a broad number of voices involved in those decisions. If users wish to use the latest versions, they must ensure they meet its requirements, this is really no different than any other BC break we do for the good of the language and its users. A couple of years ago we voted to promote 13 things to become errors / type errors, and I note you voted in favour of 12 of them, without requiring an opt-out. I must therefore assume you consider the use of undefined variables to be a legitimate coding style, and that's fine if that is your position. This RFC boils down to internals deciding, as a group, that it isn't one we want to support in future. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23/02/2022 19:32, Rowan Tommins wrote I think that wording change should be part of the proposed change in the RFC. Otherwise, a lot of people simply won't know the decision to remove it has been made and will be surprised when 9.0 comes around. It is already part of the RFC within the "proposed PHP versions" section. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23/02/2022 18:02, Nicolas Grekas wrote: I mean in addition yes, deprecation before warning. I don't see this happening. An engine warning is as stark a mechanism as we have available that you either made a mistake, or shouldn't be doing something, without preventing you from actually doing it. It may be that in 8.2 if this RFC passes that message will change to include "This will throw an error in PHP 9", but giving multiple messages for it is not beneficial IMO. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 11:23, Rowan Tommins wrote: - undefined array keys - undefined object properties - array access on a non-array - property access on a non-object I'd encourage those to be discussed, but they are unrelated to this RFC. I think most of them would pass fairly easily, but undefined array keys is out the outlier and has a reasonable chance of being rejected at this time. However, with their being 4 years before the launch of 9.0 (and the next opportunity to change it) opinion may change between now and then. I've updated the RFC to define accessing a variable as attempting to read its value for use in an expression without accounting for the possibility of it being unset. I have also included the warning message to narrow this down further, and noted that things which account for undefined variables such as isset, empty and null coalesce will remain unaffected. If there's am existing formal definition someone wishes to contribute, I'd be happy to update it. One thing maybe worth mentioning is that while most operators such as ++, +=, .= etc will be covered by this change, $undefined[] = 1; will not be. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 22/02/2022 09:15, Nicolas Grekas wrote: I very much call for an implementation to be provided before starting any vote on the topic btw. The RFC states on its first line that accessing an undefined variable emits an E_WARNING. If it does not currently emit an E_WARNING then it is out of scope of this RFC. It is not sensible to provide a full implementation for something that will require extensive engine and test changes for something several years into the future, during which many other changes will be made. A sensible time for this would be after the branch is cut for 8.4. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Setting to disable the "Undefined array index" warning
On 21/02/2022 10:29, Nicolas BADIA wrote: and I don’t find the code more readable. Here are some examples of changes: The example changes you provide are what many people here would recommend as good practice to improve the context and safety your code provides. Anyone looking at that code can immediately infer that there is an expectation that those keys may be missing, with a suitable default provided for if that is the case. The engine can see this too, which avoids it emitting warnings. It takes a little more code, yes. But that is because you're being more clear in your intent. This is a good thing. You should keep at it. You could probably have the majority of your codebase converted before you could even hold a vote. Even if the vote was passed, which seems most unlikely, you would still need to wait 10 months for 8.2 to come out to use it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 10:50, Rowan Tommins wrote: Other than an optimised implementation, there's nothing particularly special about the ++ operator's handling of null, it behaves the same as any other arithmetic operator: I would claim that the unary operators behave slightly different, if it were a case of cooerce to zero, the behaviour of null++ and null-- would be expected to be the same as operating on 0, but it's not. null++ is allowed, but null-- returns null, and its value afterwards is null. https://3v4l.org/Bnb2D If anything, it's the fact that $a++ is NOT a special case that means it will be affected by this proposal. It is intended to be affected by this proposal. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 07:48, Robert Landers wrote: Just out of curiosity, why is the 3rd case being included here? Is it just because it's currently a warning > When I first taught PHP in 2011, I was told > post-increment/decrement was sugar for `isset($var) ? $var + 1 : 1` This is not the case, there is no isset($var) involved - specficially isset($var) would first check if a variable exists and is not null (ISSET_ISEMPTY_CV), it is designed to handle undefined variables, where as most things are not. Before the increment can happen, the value in the variable must first be read. This leads to the E_WARNING for accessing an undefined variable just like any other, which this RFC seeks to prohibit. The value is then copied internally, the original value is incrementeted, and the unchanged copy is returned (its value before incrementing). The only reason this works at all is because an undefined variable read falls back to null, and the increment operator is hardcoded to treat null++ as 1. That's why if you do this: $x = $foo++; var_dump($x); You get: Warning: Undefined variable $foo in on line 3 NULL Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] Undefined Variable Error Promotion
Internals, Following on from my previous thread, I think we are now in a position where we can begin formal discussions on an RFC to promote undefined variables to Error exceptions in PHP 9.0. I present: https://wiki.php.net/rfc/undefined_variable_error_promotion I still intend to bring other error promotions forward, potentially in collaboration with other developers, but as this is the biggest change, and the most likely to attract a large number of comments, I thought it deserving of a standalone RFC. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Setting to disable the "Undefined array index" warning
On 15/02/2022 12:31, Nicolas BADIA wrote: As I’m not ready to spend weeks upgrading our codebase because our coding style is not supported by the community, I’m looking at alternatives. I don't think you'll be in luck, and should plan to get ready. As to the specific behaviour: If anything this behaviour will get tighter over time, and it's entirely possible that in a later major release it will throw an error (although that's not being proposed right now). From my conversations, there is little apetite to add additional INI based controls for engine behaviour, as they are believed to lead to inconsistencies that harm the ecosystem, rather than enhance it. Forking PHP to avoid resolving ambiguities in your code seems like it would be a false economy. Ideally you should bring your code up-to-date with what is expected, but if you are unwilling or unable to do that, you may instead wish to stay on an older version that hax more lax behaviour, and purchase LTS from the likes of Zend. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Pre RFC - __debugType() magic method
On 09/02/2022 13:49, Robin Chalas wrote: What do you think? It sounds like you need to wrap get_debug_type rather than introduce a magic method into core to account for framework oddities. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing NULL for some internal functions
On 07/02/2022 15:34, Craig Francis wrote: So are you suggesting that all the frameworks should change their default to an empty string? or every single project should update every use of these input functions to always override this default, or cast the received value to always be a string? all to avoid a Fatal Error if a NULL value ever dared to be passed to `htmlspecialchars()` and similar functions in PHP 9? I'm suggesting that every project should be specifying the default they want when they call the function. If by omission you call a function in a way that effectively says 'give me a null', then don't be surprised if it breaks when it gives you what you asked for and you pass it to something that wasn't designed for it. Special casing things is almost always the wrong approach and will lead to pain in the long run. Like "0" being the only non-empty string that's falsey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing NULL for some internal functions
On 07/02/2022 12:05, Craig Francis wrote: And specifically with NULL, strings in C are a "one-dimensional array of characters terminated by a null character", so you could say that NULL is very similar to an empty string - maybe that helps address the "pretend its a string" objection? In this case we're talking about the difference between a char* that points to a 1 byte buffer containing '\0' and a char* that itself points to NULL. Trying to perform string operations on a null pointer in C would equally blow up. With regards to your framework comment, any framework worth its salt will also have the option to provide a default value other than null when the value is not provided. It is the responsibility of the user to make use of this functionality to provide the correct type for what the soon-to-be-called function is expecting. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing NULL for some internal functions
On 07/02/2022 01:27, Craig Francis wrote: I know one person simply said this was a "terribl > idea", but I'm still waiting to hear any details on why. The changes you propose are not something that I am comfortable with either. I understand your motivations in proposing them, but to my mind it goes against the direction that PHP is developing, which I think is the right one, where errors and likely errors result in stopping execution rather than allowing it continue, potentially silently (dependent on error handling settings). If a parameter expects a string, that is what it should be given, and its the callers' responsibility to ensure that is the case. If they fail to do so then it's an error just like any other. IMHO reverting to "If it's a null we'll just pretend its a string" is contrary to how the language should be progressing. It sucks that it was ever allowed in the first place. PHP has a long history of making descisions to try to make things 'just work', and if history teaches us anything, its that we inevitably come to regret these descisions down the line. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On 29/01/2022 16:33, Christian Schneider wrote: If a static analyzer manages to catch it at development time then that is a lot better. Of course it's better, but you wouldn't argue that a car doesn't need airbags because you've tested that the breaks work. Defense in depth. Our ecosystem of static analysers are fantastic, but they're standalone tools outside the remit of internals. Maybe that software has a bug, maybe it hasn't yet been programmed to recognise the side effects of a new feature that was added, maybe the user has not updated the library in a while. With runtime checking, the engine should always try to protect against the unexpected, irrespective of if other checking has already been performed by outside sources. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On 27/01/2022 22:09, Larry Garfield wrote: I am not sure what additional value is gained by making the scream even louder. For us to make something an exception at engine level, is to stop execution on the grounds that the engine no longer considers it safe to continue. That might be because a boolean was passed to a function that expects a string, or in this case it might be because an undefined variable has been read. Notices / Warnings are irrelevant to this under the default configuration, as in the absense of a userland error handler the engine will happily allow code to continue executing even after a probably undesirable state has been detected. So what we're talking about here is changing the engine's definition of what is safe to exclude read operations on an undefined variable. I understand the argument that the behaviour is well defined, at least for some operations, but I would posit that the vast majority of reads on undefined variables are in fact unintentional side effects from branching logic and are not the real intention at all. If someone is insistent on working with nulls, there is an easy to use, fully backwards compatible way to avoid these errors, which is to define a variable as null prior to any branching logic. For everyone else, we should offer this entirely sensible safety net. What we don't want to do, I think, is end up in a situation like JS where it has to be opted in: https://www.w3schools.com/js/js_strict.asp -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On 26/01/2022 14:48, Christian Schneider wrote: Please don't flame me, I just wanted to point out that there is an opposing view on internals to consider ;-) It is my firm believe that a language such as PHP should not be dependent on static analysers to protect users against engine-level problems that may occur during runtime. Third party static analysers are great, and I am a strong proponent of Psalm. However, internals is not responsible for getting people to use a static analyser, we are responsible for the behaviour of the engine, and right now the engine is, I think, too lax in this regard. We should be aiming to provide a reasonably safe experience out the box. That you're manually patching PHP to change official behaviour (which was passed by RFC) puts your individual use case well outside of what should be considered when voting. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On 26/01/2022 17:13, Rowan Tommins wrote:
For instance, the following code is safe, useful, and readable:
$countsByDayByCategory = [];
foreach ( $someData as $item ) {
$countsByDayByCategory[ $item['day'] ][ $item['category'] ]++;
}
I myself am not planning to hold a vote on undefined array.
If there were one it would be an independent vote the same as "Undefined
Array Index" in https://wiki.php.net/rfc/engine_warnings which promoted
it to warning in 8.0.
As it's marked as a warning, I would expect it to still get upgraded at
some point in PHPs lifetime, maybe even in PHP 9, but I am not proposing
it with this batch of updates.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
Internals, PHP 9.0, likely a few years away at this point, is our next opportunity to make significant breaking changes. So I thought it would be appropriate to start a thread discussing what breaking changes we might want to include in it, specifically in relation to error handling behaviour both at engine level, and potentially library level. By discussing and passing RFCs sooner rather than later, end users and library maintainers will have much more advanced notice than if we waited until 8.4 had released. My goal is to help coordinate putting forth a set of individual RFCs, or maybe a collective set similar to https://wiki.php.net/rfc/engine_warnings that will specifically target PHP 9.0, even though that version does not yet have a release date, or even a release year. Nothing in this conversation will preclude others from passing additional RFCs in the future years that also target PHP 9 error promotion, or, for that matter, reversing those decisions potentially made here, if necessary. For my part I will be putting forward two votes which will hopefully complete the migration process started in Nikita's engine warnings RFC: ** Undefined Variables Promoted to Error ** PHP currently treats reading an undefined variable as though it were a null, emitting a warning message in the process. This was previously promoted from a notice in the PHP 8 engine warnings RFC. At the time a 3 way vote was held between promoting to an error exception, a warning, or leaving it as a notice. At the time, 56% voted in favour of throwing an Error, 28% in favour of a warning, and the remainder leaving it as a notice. My understanding is that many of those who voted to raise it to a warning did so because they felt that jumping straight from a notice to an Error was too much in one go. As it will have been a warning for around 5 years by the time PHP 9 is released, I expect that there will now be a healthy super majority to bump this up to throwing an error. ** Redefine Constants Promoted to Error / ValueError ** Attempting to redefine a constant either via 'const x' or define currently emits a warning, as well as failing. My straw poll (https://wiki.php.net/redefine_constants_exception_strawpoll) gives a strong indication that there is an appetite to promote this from a warning to an error, potentially throwing a ValueError, in PHP 9. This will bring it more into line with the result of attempting to redefine other constructs such as functions and classes. ** Other Recommendations ** Let's open a discussion as to what we might want to do in the future, and depending on how things shake out, we can decide what route to take with regards to bringing RFCs to vote. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [Strawpoll] Promoting redefining constant to exception
Internals, While cleaning up some PRs I was prompted to re-visit one I had outstanding about exception-throwing behaviour when redefining constants, this applies to functions like define and language syntax constructs such as const. There have been a few discussions in the past about the topic. Here is one from 2016 from Dmitry: https://wiki.php.net/rfc/constant_redefinition Discussion: https://externals.io/message/93885 My own PR: https://github.com/php/php-src/pull/5265 Since Dmitry's RFC was made in 2016, and my PR a while ago, attempted redeclaration was promoted from a notice to a warning, but I still think it's sensible to go one step further. There was mention on github that there was some resistence to promotion to exception in the past, but I think there is a strong possibility that the mood may be different many years later, with PHPs positive moves towards throwing on poorly defined or illogical behaviour. To gauge this, I'm throwing out a non-binding strawpoll to get the lay of the land before doing anything else with it. If there is general favour I'll fix up my patch and do a proper RFC. https://wiki.php.net/redefine_constants_exception_strawpoll Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Allow default parameters before non-default ones?
On 09/12/2021 05:22, André Hänsel wrote: This is very useful because I can add an optional parameter to a function and prevent users of my function from using the parameter in a positional way. This way I don't have to make a compatibility promise to never change the position of this parameter. I would much prefer we could find a way to give this proper support rather than a hack. I frequently use large numbers of named arguments and would very much like to be able to knock out the ability to use positional arguments, thus ensuring I can change the order (e.g. inserting a new argument after a related one) without a BC break. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion] array_column results grouping
On 05/12/2021 14:02, Rowan Tommins wrote: Since this is explicitly an open question in the current RFC draft, it seems a bit premature to talk about voting, rather than encouraging the RFC to develop in a particular direction. I hope it was taken as nothing more than an indication that adding an extra argument to array_columns would not be our preference for the route to go down :-) I could see the benefits to a standalone array_column_group function, that way the expected dimensions of the output would be more easily recognisable without having to inspect the parameters. As this RFC focuses heavily on array_columns, including all of the examples and the PR, I would encourage the author to consider an RFC specifically for array_column_group. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
