Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
On 17/01/2023 14:28, 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;
Hi George,
Thanks for tackling this. I heartily agree with the aims of this RFC;
the current situation is a weird mess of special cases, most of which
are justified only by "it's always been that way".
I am expecting the contentious part of the proposal to be the deprecation
of the PERL string increment feature to achieve the aforementioned goal.
As Craig and Mark point out, this functionality does have legitimate
uses, and I am generally of the opinion that deprecations should either
be of broken functionality (as is often the case when upgrading Warnings
to Errors) or come with specific instructions for a replacement.
Perhaps therefore we should introduce a new function, string_inc, as the
official migration path for deliberate use of this feature. This could
give the same result as the current increment operator for supported
cases, but throw an Error for cases that would currently be left
unchanged. A polyfill using the existing operator on old versions would
look something like this:
function string_inc(string $input): string {
$output = $input;
@ ++$output;
if ( $input === $output ) {
throw new Error("Unsupported input to string_inc: '$input'");
}
return $output;
}
Without the need to interact with other types or existing behaviour, I
think an accompanying string_dec would also be less controversial than
previous RFCs. Ambiguous cases like string_dec("a"), string_dec(""), and
string_dec("0") could simply throw an Error.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Measuring Proposal Reaction
I'm looking to measure reaction to a proposal. My proposal is to have the STDOUT and STDERR global constants always defined rather than just when running via CLI. The variability of their existence is a common cause of confusion for younger inexperienced devs, and even something that slips the mind of more experienced developers. My team actually internally has a sniff forbidding STDOUT and STDERR due to their unreliability in favor of fopenening php://stdout / php://stdout I think removing the environment variability between CLI and Web outweighs the potential problems of people writing to these in the wrong contexts, especially given that you can already fopen and fwrite to standard out and standard error from a web session. This is only my second RFC I've purprosed so I'm pretty new to the process. Let me know what you think and what I can do to help Thanks, Jesse G. Donat
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] [PHP_DEV] [RFC] Add file_descriptor() function
Hi On 1/16/23 16:01, G. P. B. wrote: useful when interacting with a USB device. Can some example code be added to the RFC text for those who don't understand any French? Best regards Tim Düsterhus -- 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 Jan 2023, at 14:28, G. P. B. wrote: > 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; > > I am expecting the contentious part of the proposal to be the deprecation > of the PERL string increment feature to achieve the aforementioned goal. Hi George, Just to confirm, you're suggesting the following would be broken: ``` $ref = 'A'; $ref++; var_dump($ref); // 'B' $ref = 'Z'; $ref++; var_dump($ref); // 'AA' $ref++; var_dump($ref); // 'AB' ``` 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. That said, I appreciate that incrementing some strings can be a bit unusual (e.g. "A9" to "B0", vs "A 9" to "A 0"). Craig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add SameSite cookie attribute parameter
Hi On 1/17/23 15:59, G. P. B. wrote: Side-Note: Isn't SameSite a very generic name in the global namespace? I'm not sure what the PHP policy is here. AFAIK the global namespace is "owned" by PHP so that shouldn't be an issue per the usual policy. It's still pretty generic even if it does not collide with any userland code. It would not be unlikely to have something named "SameSite" in the future that is not related to cookies, e.g. for some other HTTP-related thing. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add SameSite cookie attribute parameter
Am 17.01.2023 um 15:59 schrieb G. P. B. : > Side-Note: Isn't SameSite a very generic name in the global namespace? I'm > not sure what the PHP policy is here. > > AFAIK the global namespace is "owned" by PHP so that shouldn't be an issue > per the usual policy. In a quick check I could not find any other Enums defined in the core. Would this be the first one? I guess I was comparing it to constants where in most cases the constant name reflects where it is used, e.g. STR_PAD_LEFT and I was therefore wondering whether the name SameSite should somehow contain cookie in one form or another. Or is this frowned upon for Enums? > Are there any Enums in core PHP APIs where new values could be added in the > future and how is the plan for code supporting multiple PHP version there? > This was just something which crossed my mind when thinking about APIs with > Enums. This is not really related to this RFC so I understand if you want to > ignore this part :-) > > I might be again misunderstanding, but one cannot extend an enum as they are > final classes under the hood. > Currently, the only other native enum is the one that was added with the > Randomizer Additions RFC [1] so this topic hasn't come up yet as the enum for > ext-random is definetely complete. I'm talking about adding new values in later PHP versions, let's for example assume they would add a SameSite mode "Stricter" and PHP wants to support that. How would one write code to use "Stricter" in code meant to work for both old and new PHP versions? - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add SameSite cookie attribute parameter
On Mon, 16 Jan 2023 at 15:36, Christian Schneider wrote: > Am 16.01.2023 um 14:39 schrieb G. P. B. : > > On Sun, 15 Jan 2023 at 20:58, Christian Schneider > wrote: > > Some comments: > > - I am not convinced that we should introduce a third way of providing > parameters to setcookie(). I don't think this function is used often enough > in common code to add yet another iteration of the API. Assuming there is 1 > to 2 places in your framework using this I don't think many bugs will go > unnoticed. Adding a warning to illegal 'samesite' values in $options would > IMHO be enough if stricter checking is wished for. > > > > How is this providing a third way of providing parameters to > setcookie()? As it is, if I want to use named arguments and the typed > parameters, I cannot set the SameSite attribute. > > I've heard multiple people waste time due to a SameSite bug because they > made a typo, and it took them way too long to figure out the issue as they > thought they had a server configuration problem. > > Adding a warning for invalid values is effectively turning that option > into an Enum, which at this point one might as well have a proper Enum. > > Maybe third API was misleading, what I mean is that we had the (old) way > of positional arguments for options which did not include something like > samesite and the (new) way with the options array. So I would assume most > code was migrated to $options. > Now you are suggesting of updating the old API with an additional > positional argument which would mean changing the array-form back to > positional. > Is your plan to deprecate the $options-API at some point in the future? > Having two APIs offering the same functionality seems a bit confusing to me. > I personally don't plan on deprecating the array $options API. If two APIs that provide the same functionality are too confusing, then the current incomplete way of passing parameters should be deprecated at some point. However, until then, having symmetry between both APIs is better for people who prefer to have parameters and use named arguments than the $options array. > Alternatively the 'samesite' option in $options could accept > SameSite::Lax. This would accomplish (almost) the same with a smaller > change. Disclosure: I like arrays for options as they allow for array > addition etc. Something similar can be done with ...$options, true :-) > That is actually a good idea to add support for the array version to accept the new enum, I'll amend the implementation. > Side-Note: Isn't SameSite a very generic name in the global namespace? I'm > not sure what the PHP policy is here. > AFAIK the global namespace is "owned" by PHP so that shouldn't be an issue per the usual policy. > > - I don't like the camelCase of $sameSite as this is different from > all the other parameters, e.g. $expires_or_options (yes, this is a > pseudo-parameter name, I know) and $httponly. Looking at a couple of > functions in the standard PHP set I didn't see any $camelCase. > > > > ACK, it should probably be in snake case and be $same_site > > Looking at $httponly I would have expected $samesite. > I suppose it can be either or, but trying to improve the name of a not yet existing parameter seems better than following the weird naming scheme. But I'm not hard set on the name here. > > - A more generic question: How are Enums handled concerning future > additions of values vs. BC compatibility? What is the migration plan there > if one wants to support both old and new PHP versions? > > > > The parameter is optional, so I don't understand what migration plan you > need? > > If in the, unlikely, event that a new value is added this should be > added as a case in the enum in the next minor version of PHP. > > In the, again unlikely, event that a value is deprecated, the > corresponding enum case should also be deprecated following the normal PHP > deprecation process. > > > > I only decided to make this an enum because I deem it very unlikely for > a new valid attribute value to be introduced, the new IETF RFC clarifies > and amends the behaviour of the 3 valid attribute values that have always > been the same since 2016. > > I was talking about extending Enums, not the parameter and not SameSite > specifically. > Are there any Enums in core PHP APIs where new values could be added in > the future and how is the plan for code supporting multiple PHP version > there? This was just something which crossed my mind when thinking about > APIs with Enums. This is not really related to this RFC so I understand if > you want to ignore this part :-) > I might be again misunderstanding, but one cannot extend an enum as they are final classes under the hood. Currently, the only other native enum is the one that was added with the Randomizer Additions RFC [1] so this topic hasn't come up yet as the enum for ext-random is definetely complete. Best, George P. Banyard
[PHP-DEV] [RFC] Saner array_(sum|product)()
Hello internals, I would like to start the discussion about the Saner array_(sum|product)() RFC: https://wiki.php.net/rfc/saner-array-sum-product Currently, the array_sum() and array_product() behave differently than their userland implementation as they ignore arrays and objects, and cast the remaining types to int/float. This is in contrast with the behaviour of arithmetic operators that throw TypeErrors on types and values that are not interpretable as int/float. This RFC aims to resolve this discrepancy. Best regards, George P. Banyard
[PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
Hello Internals, 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; I am expecting the contentious part of the proposal to be the deprecation of the PERL string increment feature to achieve the aforementioned goal. However, I believe the benefits of aligning the behaviour of the increment/decrement operators with addition/subtraction are larger than keeping support for the PERL increment, which in its current state has various shortcomings. Best regards, George P. Banyard
