Re: [PHP-DEV] RFC [Discussion]: mb_str_pad
Hello, As this is a new function do you consider any namespace for it? Based on passed RFC[1] allowing for namespaces in bundled extensions it would be nice to introduce new functions with namespace. Maybe the namespace could be voted in the RFC separately? Kind regards, Jorg [1] https://wiki.php.net/rfc/namespaces_in_bundled_extensions
Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231
> What do you mean? Do you mean that the constant was legal at some point? Sorry, but I don't have this knowledge. It's invalid since 2004, but I suppose this format was implemented before then. Undoubtedly the format is invalid now. The usage in 1000 most popular libraries: DATE_ISO8601 (4 packages, 1 in comments) DateTimeInterface::ISO8601 (18 packages) DateTimeInterface::RFC7231 (1 package - Jetbrains/phpstorm-stubs) DATE_RFC7231 (1 package - Jetbrains/phpstorm-stubs) Most of the packages already inform about deprecation. PHP stubs by Jetbrans warn about deprecation, although it's not officially.
Re: [PHP-DEV] rounding integers
On Sun, May 21, 2023, at 7:18 AM, Rowan Tommins wrote: > On 21 May 2023 13:00:30 BST, Dan Ackroyd wrote: >>On Sun, 21 May 2023 at 06:16, Marc wrote: >>> >>> Do you think this could be an acceptable BC-break >> >>No. Suggesting changing a 30 year old maths operations is a huge BC break. >> >>> or should this be a different function? >> >>Just make your own that does precisely what you want... > > I agree on the first point, but disagree on the second. It's far too > late to change round() itself, but the lack of built-in functions for > converting to int in a controlled way is frustrating, particularly as > the fashion moves towards stronger typing in general. > > On the surface, it sounds like a trivial operation, but there's a lot > of edge cases to think about (limits of FP precision, negatives > including negative zero, etc), and shipping a robust implementation of > int_round, int_floor and int_ceil in core would save everyone having to > rediscover them the hard way. Having recently been bitten by floor() returning a float even though the value that comes back is logically an int, I would be fully in support of "and returns an int" versions of these functions in core. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] rounding integers
On 21 May 2023 13:00:30 BST, Dan Ackroyd wrote: >On Sun, 21 May 2023 at 06:16, Marc wrote: >> >> Do you think this could be an acceptable BC-break > >No. Suggesting changing a 30 year old maths operations is a huge BC break. > >> or should this be a different function? > >Just make your own that does precisely what you want... I agree on the first point, but disagree on the second. It's far too late to change round() itself, but the lack of built-in functions for converting to int in a controlled way is frustrating, particularly as the fashion moves towards stronger typing in general. On the surface, it sounds like a trivial operation, but there's a lot of edge cases to think about (limits of FP precision, negatives including negative zero, etc), and shipping a robust implementation of int_round, int_floor and int_ceil in core would save everyone having to rediscover them the hard way. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] rounding integers
On Sun, 21 May 2023 at 06:16, Marc wrote: > > Do you think this could be an acceptable BC-break No. Suggesting changing a 30 year old maths operations is a huge BC break. > or should this be a different function? Just make your own that does precisely what you want... cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
