Re: [PHP-DEV] RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
Hi Daniele,
I think many of these functions might already be part of popular userland
libraries like Symfony String component
https://symfony.com/doc/current/components/string.html#methods-added-by-bytestring
It might be worthwhile to add missing functions to such userland libraries.
Imho, PHP stdlib has enough string functions for allowing developers to
write polyfills in userland code fairly easily.
Regards,
Faizan
On Sat, 25 Sep 2021, 10:50 pm Daniele B via internals, <
internals@lists.php.net> wrote:
>
> Hi Kamil,
> Thx a lot. I try to build a list specifying when it is matter of Classic
> ASP.This mailing list doesn't support a lot of code per post..
>
> String Manipulation==
> function is_contraction(?string $w) {}
> function is_givenName(?string $w) {}
> function is_ucfirst(?string $s) {}
>
>
>
> function is_vowel(string $letter) {}
> // Classic ASP
> function left(?string $string, int $length) {}
> function leftWord(?string $phrase) {}
> function rightWord(?string $phrase) {}
>
>
>
> // Classic ASPfunction right(?string $string, int $length) {}
> // Classic ASPfunction space();
> function str_case_normalize(?string $text) {}
>
>
>
> function str_place(string $string, string $needle) {}
> function str_phrase_reverse(string $string) {}
>
>
>
> function str_word_unique(string $phrase, bool $removeRightMost = true) {}
> function rtrim_word(string $phrase, array $aWords) {}
> function trim_word(string $phrase, array $aWords) {}
>
>
>
>
> etc. etc.
> Next call we talk about date and time..
>
> Daniele Boninihttp://github.com/par7133
>
>
>
>
>
>
>
> Original message
> From: Kamil Tekiela
> Date: 9/25/21 16:49 (GMT+01:00)
> To: daniele bonini
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] RFC Concept: "Import" of simplied string
> manipulation and other instructions from ASP Classic
>
>
> Hi Daniele,
> Thanks for reaching out to internals. I am curious about your proposal.
> Could you please provide some examples of what you think was great in
> Classic ASP that you would like to see implemented in PHP? If you have
> implemented polyfills in PHP for them, could you share them with us?
> Regards,Kamil
>
>
Re: [PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?
> On Sep 25, 2021, at 12:03 PM, Marco Pivetta wrote: > > Hey Tyson, > > On Sat, 25 Sep 2021, 18:00 tyson andre, wrote: > >> My original message had a section with reasons why an end user might want >> that. >> > > Yeh, it sounds like stuff we wanna get away from Point of order here: "we" is not unanimous. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: RFC Concept: "Import" of simplied string man ipulation and other instructions from ASP Classic
On 25 September 2021 22:22:51 BST, Daniele B wrote:
Rowan, I did the bithday party of my two years old daughter yesterday.. if I
knew before I wrote you about this topic a couple of days ago to invite you all
to the party.. ; ) I'm not here exacly to meet up you my github account..
Well, since your github account is already linked at the bottom of all
your e-mails, I'm not sure what the concern is, but github gists was
just one suggestion. My point was that there are plenty of places online
where you could post the code you were trying to share, and then you
wouldn't have to fit it into an e-mail.
I also invested a good half of day about this *simplification* topic.. sorry.
Sure, and I have invested time trying to understand what you're
proposing, and to help you make your case to other people. If you
succeed, other people will be investing time to implement these
functions, and document and maintain them. As the saying goes: there is
no such thing as a free lunch.
About the "magic" tilde is nothing else an help to not break in the 0 position
OK. The correct way to do that, as mentioned in the manual for strpos(),
is to do a strict comparison against false. So your function can be
written as:
function str_place(string $haystack, string $needle): string
{
if ( mb_stripos($haystack, $needle) !== false ) {
return $needle;
}
else {
return PHP_STR;
}
}
Or more concisely:
function str_place(string $haystack, string $needle): string
{
return mb_stripos($haystack, $needle) === false ? PHP_STR : $needle;
}
I've still no idea what PHP_STR is, what the function name means, or
when it is useful, though.
about the rest of your comments are merely about your aesthetic tast that
probably is different from mine
I'm not saying I don't *like* these functions, I'm saying I genuinely
don't know what they do.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: RFC Concept: "Import" of simplied string man ipulation and other instructions from ASP Classic
Rowan, I did the bithday party of my two years old daughter yesterday.. if I knew before I wrote you about this topic a couple of days ago to invite you all to the party.. ; ) I'm not here exacly to meet up you my github account..I also invested a good half of day about this *simplification* topic.. sorry.About the "magic" tilde is nothing else an help to not break in the 0 position, about the rest of your comments are merely about your aesthetic tast that probably is different from mine..What's that? I need to call for web developers who consume php?Well, I was thinking to PHP like a software project.. Daniele Boninihttp://github.com/par7133 - Original message -From: rowan+dot+collins+at+gmail+dot+comDate: Sat, 25 Sep 2021 20:55:02 +Subject: Re: RFC Concept: "Import" of simplied string man ipulation and other instructions from ASP Classic On 25 September 2021 21:17:22 BST, Daniele B wrote: >Hi Rowan, >Unfortunately I can't post all the code here by the mailing list cause the >message size limit. Well, that's easily solved: put it online, as a github gist, a blog post, wherever you like, and link to that. However, much better than the code would be one-line summaries of what these functions are *for*. Your code for str_place leaves me more confused than before: What's the magic tilde for? What's the other magic value in the else clause? And why is it called "place"? Similar questions arise for a lot of the other functions you mention. I suspect the problem is that you've been using them for years, so they feel obvious to you. You need to step back, imagine you'd never heard of them before, and explain why *those particular functions*, of the millions of possible helpers, should be added to PHP. Regards, -- Rowan Tommins [IMSoP]
[PHP-DEV] Re: RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
On 25 September 2021 21:17:22 BST, Daniele B wrote: >Hi Rowan, >Unfortunately I can't post all the code here by the mailing list cause the >message size limit. Well, that's easily solved: put it online, as a github gist, a blog post, wherever you like, and link to that. However, much better than the code would be one-line summaries of what these functions are *for*. Your code for str_place leaves me more confused than before: What's the magic tilde for? What's the other magic value in the else clause? And why is it called "place"? Similar questions arise for a lot of the other functions you mention. I suspect the problem is that you've been using them for years, so they feel obvious to you. You need to step back, imagine you'd never heard of them before, and explain why *those particular functions*, of the millions of possible helpers, should be added to PHP. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
Hello David,
> I can agree with you that the current ways are a bit confusing for a
beginner..
You got the point of my shaking hand for simplification. Although I state you
here thatas freelancer, thinking to new ideas, public web apps, finding
customers, contracts,client retention.. further than coding and projecting.. I
will hope to remain a "PHP beginner" still for a long time (?).
If we talk about syntax a month() function is simple and date("i") is a
complication.Then I agree with you that is easy for anyone to write this month
function.. But, then, asI can't force anyone on my ideas, become just matter of
"beauty"? It is that?So about simplification we do not agree a lot, maybe..
However, I invite you to not solve this RFC Concept with a 3rd party package.
My ownpersonality is so frustrating - what a pain.. - that I force myself to
not install any3rd party package on my server.
Daniele Boninihttp://github.com/par7133
-- Original message --From: david.proweb@gmail.comDate: Sat, 25 Sep
2021 20:00:56 +Subject: Re: RFC Concept: "Import" of simplied string
manipulation and other instructions from ASP Classic
Hello!
Why are the current date() alternatives not working for you?
- is_date() => checkdate(int $month, int $day, int $year) or
DateTime::createFromFormat('Y-m-d', $date) !== false;
- year() => date('Y');
- month() => date('m');
- day() => date('d');
- hour() => date('H');
- minute() => date('i');
- second() => date('s');
- week() => date('W');
I can agree with you that the current ways are a bit confusing for a
beginner. For example, I myself didn't know the representation of weeks
using date() -- I had to search. But I think creating new "root functions"
would be too much. Perhaps a package like Carbon could be very useful. Or
even the DateTime itself.
Atenciosamente,
David Rodrigues
[PHP-DEV] Re: RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
Hi Rowan,Unfortunately I can't post all the code here by the mailing list cause
the message size limit.Kamil should has received by mistake a couple of sents
with the code, my tries.
Here however the code for str_place:
declare('PHP_TILDE', "~");function str_place(string $string, string $needle):
string
{
if (mb_stripos(PHP_TILDE . $string, $needle)) {
return PHP_STR;
} else {
return $needle;
}
}
Forgive also my typing, the subject is mostly about *simplication* also if
undubtly Im talking of Classic ASP too.The problem that here arise is exatly
this philosophic matter: how much easy is easiest? I like the easiest, I don't
need to show my reputation to write down a complicate "left".. the countrary is
true..In facts Im exactly pointing out that Classic Asp was doing all those
stuff easier, maybe withoutneed for the developer to memorize covulsive date
time parameters, or add one more parameter to do call a "left"function, maybe
nested..
Daniele Boninihttp://github.com/par7133
-- Original Message --From: Rowan Collins Hi
Daniele,
On 25 September 2021 18:18:59 BST, Daniele B via internals
wrote:
>
>Thx a lot. I try to build a list specifying when it is matter of Classic
>ASP.This mailing list doesn't support a lot of code per post..
Rather than focusing on how they relate to Classic ASP, a better approach might
be to look at how proposed functions would fit with other things in PHP, and
how widely used they would be. There are lots of languages we can borrow ideas
from, but the goal should be to pick the best bits and adapt them as needed.
Some of these are quite easy to do in PHP - for instance, left() and right()
are simple with substr(); and str_place() sounds exactly like strpos() from the
name.
It looks like there is a family of functions related to "words" (presumably
splitting on space?); perhaps there is a core set that would make the others
easier?
Finally, remember that a lot of people reading this have never used Classic
ASP, so don't know what these functions do. Some are easy to guess, but others
less so, such as is_contraction(), is_givenName(), space(), and
str_case_normalize()
Regards,
--
Rowan Tommins
[IMSoP]
Re: [PHP-DEV] RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
Hello!
Why are the current date() alternatives not working for you?
- is_date() => checkdate(int $month, int $day, int $year) or
DateTime::createFromFormat('Y-m-d', $date) !== false;
- year() => date('Y');
- month() => date('m');
- day() => date('d');
- hour() => date('H');
- minute() => date('i');
- second() => date('s');
- week() => date('W');
I can agree with you that the current ways are a bit confusing for a
beginner. For example, I myself didn't know the representation of weeks
using date() -- I had to search. But I think creating new "root functions"
would be too much. Perhaps a package like Carbon could be very useful. Or
even the DateTime itself.
Atenciosamente,
David Rodrigues
Em sáb., 25 de set. de 2021 às 16:48, Daniele B via internals <
internals@lists.php.net> escreveu:
> Here we go with a list of Date and time functions:
> // Classic Aspfunction is_date(string $date) {}function year(?string
> $date) {}function month(?string $date) {}function day(?string $date)
> {}function hour(?string $date) {}function minute(?string $date) {}function
> second(?string $date) {}function weekday(?string $date) {}
> //other stuff to simplify:function date_add() {}
>
>
>
> Original message
> From: Kamil Tekiela
> Date: 9/25/21 16:49 (GMT+01:00)
> To: daniele bonini
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] RFC Concept: "Import" of simplied string
> manipulation and other instructions from ASP Classic
>
> Hi Daniele,
> Thanks for reaching out to internals. I am curious about your proposal.
> Could you please provide some examples of what you think was great in
> Classic ASP that you would like to see implemented in PHP? If you have
> implemented polyfills in PHP for them, could you share them with us?
> Regards,Kamil
>
Re: [PHP-DEV] RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
Hi Daniele, On 25 September 2021 18:18:59 BST, Daniele B via internals wrote: > >Thx a lot. I try to build a list specifying when it is matter of Classic >ASP.This mailing list doesn't support a lot of code per post.. Rather than focusing on how they relate to Classic ASP, a better approach might be to look at how proposed functions would fit with other things in PHP, and how widely used they would be. There are lots of languages we can borrow ideas from, but the goal should be to pick the best bits and adapt them as needed. Some of these are quite easy to do in PHP - for instance, left() and right() are simple with substr(); and str_place() sounds exactly like strpos() from the name. It looks like there is a family of functions related to "words" (presumably splitting on space?); perhaps there is a core set that would make the others easier? Finally, remember that a lot of people reading this have never used Classic ASP, so don't know what these functions do. Some are easy to guess, but others less so, such as is_contraction(), is_givenName(), space(), and str_case_normalize() Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
Here we go with a list of Date and time functions:
// Classic Aspfunction is_date(string $date) {}function year(?string $date)
{}function month(?string $date) {}function day(?string $date) {}function
hour(?string $date) {}function minute(?string $date) {}function second(?string
$date) {}function weekday(?string $date) {}
//other stuff to simplify:function date_add() {}
Original message
From: Kamil Tekiela
Date: 9/25/21 16:49 (GMT+01:00)
To: daniele bonini
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC Concept: "Import" of simplied string manipulation
and other instructions from ASP Classic
Hi Daniele,
Thanks for reaching out to internals. I am curious about your proposal. Could
you please provide some examples of what you think was great in Classic ASP
that you would like to see implemented in PHP? If you have implemented
polyfills in PHP for them, could you share them with us?
Regards,Kamil
Re: [PHP-DEV] RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
Hi Kamil,
Thx a lot. I try to build a list specifying when it is matter of Classic
ASP.This mailing list doesn't support a lot of code per post..
String Manipulation==
function is_contraction(?string $w) {}
function is_givenName(?string $w) {}
function is_ucfirst(?string $s) {}
function is_vowel(string $letter) {}
// Classic ASP
function left(?string $string, int $length) {}
function leftWord(?string $phrase) {}
function rightWord(?string $phrase) {}
// Classic ASPfunction right(?string $string, int $length) {}
// Classic ASPfunction space();
function str_case_normalize(?string $text) {}
function str_place(string $string, string $needle) {}
function str_phrase_reverse(string $string) {}
function str_word_unique(string $phrase, bool $removeRightMost = true) {}
function rtrim_word(string $phrase, array $aWords) {}
function trim_word(string $phrase, array $aWords) {}
etc. etc.
Next call we talk about date and time..
Daniele Boninihttp://github.com/par7133
Original message
From: Kamil Tekiela
Date: 9/25/21 16:49 (GMT+01:00)
To: daniele bonini
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC Concept: "Import" of simplied string manipulation
and other instructions from ASP Classic
Hi Daniele,
Thanks for reaching out to internals. I am curious about your proposal. Could
you please provide some examples of what you think was great in Classic ASP
that you would like to see implemented in PHP? If you have implemented
polyfills in PHP for them, could you share them with us?
Regards,Kamil
Re: [PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?
On 25/09/2021 16:45, tyson andre wrote: What are your thoughts on allowing the `(object)` cast in initializer types where `new` was already allowed I'm not strongly opposed to this, but am not convinced it's a big improvement. Firstly, as with everything involving stdClass, I would be more interested in a) improving the initialization of anonymous objects, and b) allowing those in initialisers (the RFC currently forbids them, but doesn't say why, so I'm not sure if it's an implementation decision or a philosophical one). Secondly, if you have enough knowledge of the structure to provide an inline default, then you probably have enough to be worth defining a named class, even if that class then implements __set() to allow additional ad hoc properties. That class can then have its own defaults, so that your example becomes `function setData(Data $values = new Data())` Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?
Hey Tyson, On Sat, 25 Sep 2021, 18:00 tyson andre, wrote: > My original message had a section with reasons why an end user might want > that. > Yeh, it sounds like stuff we wanna get away from > Not a push for getting rid of stdClass. Way too many things use stdClass > to get rid of stdClass. > Yes, but for legacy reasons, not for further perpetuating the practice. >
Re: [PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?
Hey Marco Pivetta,
> > What are your thoughts on allowing the `(object)` cast in initializer types
> > where `new` was already allowed, but only when followed by an array literal
> > node. (e.g. continue to forbid `(object)SOME_CONSTANT`) (see
> > https://wiki.php.net/rfc/new_in_initializers)
> > ...
> > Reasons:
> > - The ability to construct empty stdClass instances but not non-empty ones
> > is something users would find surprising,
> > and a lack of support for `(object)[]` be even more inconsistent if
> > factory methods were allowed in the future.
> > - stdClass is useful for some developers, e.g. in unit tests, when using
> > libraries requiring it for parameters,
> > when you need to ensure data is encoded as a JSON `{}` rather than `[]`,
> > etc.
> > - It would help developers write a clearer api contract for methods,
> > e.g. `function setData(stdClass $default = (object)['key' => 'value'])`
> > is clearer than `function setData(?stdClass $default = null) { $default
> > ??= (object)['key' => 'value']; `
> > - stdClass may be the only efficient built-in way to represent objects with
> > arbitrary names if RFCs such as https://externals.io/message/115800 passed
> passed
>
> Right now, there's even an interest in getting rid (or deprecating) dynamic
> properties on objects: why push the complete opposite ways?
>
> What is the actual value of using an stdClass instance instead of an
> `array` (already supported)?
My original message had a section with reasons why an end user might want that.
There's a push for getting rid of (or deprecating) dynamic properties on
**objects that are not stdClass (or subclasses)**
Not a push for getting rid of stdClass. Way too many things use stdClass to get
rid of stdClass.
(whether or not stdClass gets aliased or even renamed to DynamicObject).
```
php > var_dump(json_decode('{}'));
object(stdClass)#1 (0) {
}
```
Thanks,
Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?
Hey Tyson, On Sat, 25 Sep 2021, 17:45 tyson andre, wrote: > What are your thoughts on allowing the `(object)` cast in initializer > types where `new` was already allowed, but only when followed by an array > literal node. (e.g. continue to forbid `(object)SOME_CONSTANT`) (see > https://wiki.php.net/rfc/new_in_initializers) > Right now, there's even an interest in getting rid (or deprecating) dynamic properties on objects: why push the complete opposite ways? What is the actual value of using an stdClass instance instead of an `array` (already supported)? >
[PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?
Hi internals,
In PHP 8.1, it is possible to allow constructing any class name in an
initializer, after the approval of https://wiki.php.net/rfc/new_in_initializers
```
php > static $x1 = new ArrayObject(['key' => 'value']);
php > static $x2 = new stdClass();
php > static $x3 = (object)['key' => 'value'];
Fatal error: Constant expression contains invalid operations in php shell code
on line 1
```
What are your thoughts on allowing the `(object)` cast in initializer types
where `new` was already allowed, but only when followed by an array literal
node. (e.g. continue to forbid `(object)SOME_CONSTANT`) (see
https://wiki.php.net/rfc/new_in_initializers)
stdClass has never implemented a factory method such as `__set_state` (which is
not yet allowed). Instead, `(object)[]` or the `(object)array()` shorthand is
typically used when a generic object literal is needed. This is also how php
represents objects in var_export.
```
php > var_export(new stdClass());
(object) array(
)
```
Reasons:
- The ability to construct empty stdClass instances but not non-empty ones is
something users would find surprising,
and a lack of support for `(object)[]` be even more inconsistent if factory
methods were allowed in the future.
- stdClass is useful for some developers, e.g. in unit tests, when using
libraries requiring it for parameters,
when you need to ensure data is encoded as a JSON `{}` rather than `[]`, etc.
- It would help developers write a clearer api contract for methods,
e.g. `function setData(stdClass $default = (object)['key' => 'value'])`
is clearer than `function setData(?stdClass $default = null) { $default ??=
(object)['key' => 'value']; `
- stdClass may be the only efficient built-in way to represent objects with
arbitrary names if RFCs such as https://externals.io/message/115800
passed
Thanks,
Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
Hi Daniele, Thanks for reaching out to internals. I am curious about your proposal. Could you please provide some examples of what you think was great in Classic ASP that you would like to see implemented in PHP? If you have implemented polyfills in PHP for them, could you share them with us? Regards, Kamil
[PHP-DEV] RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
Hello Everyone, I'm not here to to enter in "mysterious RFC processes" nor I want "to change the web", sorry for that.But I think that this notice is due from the fact that playing for your own reputation nowadays is a quite a common game. And after all my proposal comes as request of "simplification" of my programming life, and hopefuly yours. Neither I will feel depressed if my past love for ASP Classic is not imported in PHP: simply because this doesn't want to be a romantic recall of the past, neither..However: for the most curious and *info hungriest* I can confirm you that ASP Classic has been around for a lot of time and still is *silently* implemented for some mere intranet, extranet and websites. Time-to-time I still break on Classic ASP websites but frankly the language is promoted for a silent disapperance. And this obvious to all. Prefance finished. Since when I started to switch to PHP development I found myself failing sometimes on obstruct syntax and not so simple-as-on-the-go instructions. On the obstruct syntax, I fixed my coding erasing the more naif syntax or deprecated or unsafe code. On the simplicity, I found myself within the need to replicate a lot of Classic ASP simple instructions (mostly time and dates, string manipulation instructions, etc) and starting a sort of PHP Simplification Process on some other instructions like is_set that became is_set1, accepting a default value; adding to filtring functionalities, by reg expressions; etc, etc. Why this RFC Concept? Well, I finally found myself keeping around with a couple (also a dozen) of includes files with "simplified functions" that probably you are in good habbits to create by your own too - maybe. Second, missing the the second factor in a "mystical war" between languages (see Classic ASP), I don't see the reason why we can look to "import" some good stuff from there simplifing the developement process of all for the better? Waiting your considerations and.. Hope this helps! Daniele Boninihttp://github.com/par7133
Re: [PHP-DEV] BC breaking changes in PHP 8.1
On Thu, 23 Sept 2021 at 17:53, Nikita Popov wrote: > I believe the changes in PHP 8.1 with the highest migration burden for > open-source libraries are the additional of tentative return types (aka > "put #[ReturnTypeWillChange] everywhere") and deprecation of null arguments > to internal functions, followed by the float to int precision-loss > deprecation and, depending on project, the Serializable deprecation. > > [...] > > I'm not sure what we can do about that though. Sure, we could stop with the > (runtime) deprecations, only document the change and then directly > implement it at the next major version. That would be much simpler for us > (generating runtime deprecations is actually a major implementation pain, > as well as a big performance concern) and would make minor version upgrades > for libraries much simpler. However, it also removes the ability to address > problems before they turn into fatal errors, e.g. by recording any stray > deprecation warnings in production. > While "put #[ReturnTypeWillChange] everywhere" has been fairly easy... "deprecation of null arguments to internal functions" is a major issue, because they are everywhere, and only really found at run-time... and tbh, I can't explain to anyone why it's so important this will be broken in the future, especially for the majority of projects who are not using `strict_types=1`. Don't get me wrong, a user/library defined function that says it only wants a string, I get that, but they have full control over it (for their projects) so they can be as strict as they like, or use `?string`... but the internals functions have always accepted NULL, and used by everyone. As I noted last week, frameworks use NULL for undefined GET/POST/COOKIE values, so these NULL get everywhere; and it can be useful to distinguish between a value that wasn't set vs an empty string (e.g. when saving to a database, a NULL can be "do not change", which is different to "set this field to an empty string"). One of the projects I work with have gone down the route of "check it, but you should probably stick `strval()` in every case of `strlen()`, `trim()`, `strpos()`, `htmlspecialchars()`, `strtoupper()`, `hash()`, `hash_equals()`, `simplexml_load_string()`, `strtotime()`, `explode()`, etc"... which really doesn't seem sensible (one commit was over 200 manually checked/changed lines, and took about 3 days)... the other projects have gone with the "we can stick on 8.0 for a while, hopefully things change". Maybe PHP 8.1 could be updated so these string functions could continue accepting NULL? Craig
Re: [PHP-DEV] BC breaking changes in PHP 8.1
Am 23.09.2021 um 18:52 schrieb Nikita Popov: I believe that this continues to be the default behavior of PHPUnit for example. This means that in practice, deprecations do break code, even though they are intended not to. That is correct: by default, PHPUnit converts PHP deprecations, errors, notices, and warnings to exceptions. While disabling the conversion of PHP deprecations to exceptions, for instance, is possible by setting convertDeprecationsToExceptions="false" in your PHPUnit XML configuration file, I do think that the default should be changed to not covert PHP deprecations to exceptions. The next releases of PHPUnit 8.5 and PHPUnit 9.5 will change this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
