Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231
>outdated format, standard has been changed while ago What do you mean? Do you mean that the constant was legal at some point? Was there ever a version of ISO8601 allowing the mixing of "extended format" and "basic format" ? The earliest version I've read, iso8604:2004, does not allow it (more on that here: https://externals.io/email/114883/source - can't find the proper link right now, am on phone). Haven't read the older 1988/1999/2000 versions, and it's possible one of those allowed it, but I doubt it. The only thing I can say for sure is that it's been illegal since the 2004 version On Fri, May 19, 2023, 23:17 Jorg Sowa wrote: > > How common is it in the wild? I am pretty sure I've used it myself > without really thinking many times, which I suspect is common. Knowing how > much code would be impacted would determine how we'd go about deprecating > it and on what timeline. > > I'm not sure how would be possible to find out. I suppose most of the > frameworks (and thus popular PHP libraries) avoid this constant as showed > in Drupal and Carbon. The scanning of popular libraries will not show the > scale of the problem (however I will do it tomorrow) Helpful fact is that > those constants are just constants so it's easily replaceable with > strings 'Y-m-d\\TH:i:sO' > and 'D, d M Y H:i:s \\G\\M\\T'. >
Re: [PHP-DEV] [RFC] Property hooks, nee accessors
I can't wait! Especially because I'm heading a modernization of the systems in my organization and my plan is to use the cutting edge PHP version for it. Currently our internal "framework" uses PHP 7.4, but with a PHP 5.6 coding style. Again: I can't wait! I can't do much but thank everyone who spends their time to make PHP evolve. Thank you all! Regards, Erick Em sex., 19 de mai. de 2023 às 17:48, Larry Garfield escreveu: > On Mon, May 8, 2023, at 9:38 PM, Larry Garfield wrote: > > Ilija Tovilo and I would like to offer another RFC for your > > consideration. It's been a while in coming, and we've evolved the > > design quite a bit just in the last week so if you saw an earlier draft > > of it in the past few months, I would encourage you to read it over > > again to make sure we're all on the same page. I'm actually pretty > > happy with where it ended up, even if it's not the original design. > > This approach eliminates several hard-to-implement edge cases while > > still providing a lot of functionality in one package. > > > > https://wiki.php.net/rfc/property-hooks > > Hi folks. Based on feedback we've made a few smaller changes to the RFC. > > Changelog: > > * The sections describing isset/unset and magic methods have been > rewritten to be clearer. Nothing changed in the actual behavior, it is now > just explained better. > > * Contravariance on the "set" type is now enforced. Ilija figured out how > to make it work. :-) That means a non-contravariant type on the set hook > will now throw an error, as expected. > > * After extensive discussion with Nicolas Grekas, we've decided to allow > references in a very narrow case. Specifically, on a *virtual property* > (one that has no inherent backing store), you may implement a `&get` hook > instead of `get`, and the value it returns will be returned by reference, > and may be captured using $foo =& $bar->baz; We determined that it is a > bit better for BC (in the rare cases that you actually want to get a > reference to a property, you can, even if it requires a little more work), > doesn't break anything else, and is consistent with the way `&__get` > behaves. __get/__set are basically "anonymous virtual properties", so now > they behave the same way. By the same token, setting by reference is still > not allowed, which is also true for __set today. > > As there was no other interest in it stated, we're going to hold off on an > `unset` hook at this time. Given the earlier discussion I think there is a > valid use case for it, so it would be a worthwhile follow up RFC in the > future, but for the moment we want to keep it simple. > > There also doesn't seem to be much interest in specifying which hook gets > the double-shortened syntax. I can see the argument for it, but it would > increase the typing in a common case for an unclear benefit, and only one > person expressed any interest in it. So we're not going to go that route. > > There's two items still pending. > > 1. Ilija is experimenting with the `parent::$prop::get()` syntax, to see > if either the syntax or implementation can be simplified. There may or may > not be a small change here as a result, TBD. > > 2. Ilija still has to verify that foreach() can work with virtual > properties as the RFC currently describes. The implementation details are > thornier than they seem, so that still needs some validation and testing. > > Assuming both of those get sorted out soon, we will probably call a vote > around the end of the month, give or take. > > Cheers. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
[PHP-DEV] RFC [Discussion]: mb_str_pad
Hello internals I'm opening the discussion for my RFC to implement mb_str_pad. RFC: https://wiki.php.net/rfc/mb_str_pad Implementation pull request: https://github.com/php/php-src/pull/11284 Kind regards Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: mb_str_pad
On 20 May 2023 13:53:20 BST, Niels Dossche wrote:
>RFC: https://wiki.php.net/rfc/mb_str_pad
Hi Niels,
This seems like a reasonable addition. My only hesitation is that it will share
with other mbstring functions the slightly dubious definition of "character" as
"code point", rather than "grapheme", when dealing with Unicode strings.
This is most easily demonstrated using combining diacritics, e.g.
"Franc\u{0327}ais" is 9 code points long, but visually identical to the 8 code
point "Fran\u{00E7}ais" used in your examples. Unicode defines "graphemes" or
"grapheme clusters" to better match the common intuition of what a "character"
means.
Perhaps we should instead, or also, add a "grapheme_strpad" function to
ext/intl?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: mb_str_pad
Hi Rowan
On 5/20/23 17:13, Rowan Tommins wrote:
> On 20 May 2023 13:53:20 BST, Niels Dossche wrote:
>> RFC: https://wiki.php.net/rfc/mb_str_pad
>
> Hi Niels,
>
> This seems like a reasonable addition. My only hesitation is that it will
> share with other mbstring functions the slightly dubious definition of
> "character" as "code point", rather than "grapheme", when dealing with
> Unicode strings.
>
> This is most easily demonstrated using combining diacritics, e.g.
> "Franc\u{0327}ais" is 9 code points long, but visually identical to the 8
> code point "Fran\u{00E7}ais" used in your examples. Unicode defines
> "graphemes" or "grapheme clusters" to better match the common intuition of
> what a "character" means.
>
Thanks for your insight.
This is a good point. I've added a clarification in the RFC text to make clear
the definition of character is code point in this case, consistent with
mbstring.
> Perhaps we should instead, or also, add a "grapheme_strpad" function to
> ext/intl?
>
> Regards,
>
I've added this suggestion to the future scope section.
Kind regards
Niels
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])
On Thu, May 18, 2023 at 9:12 AM Marco Pivetta wrote: > > Would it perhaps make sense to have this in userland first, in phpstan or > psalm plugins, to see if there is interest? > 100% this in my view; this is exactly the kind of check which you would expect to be done at the static analysis stage and I don't see a benefit to new behavior in the engine here. Allowing us as PHP users to add whatever kind of metadata and tooling to interpret it we find useful is exactly what user-defined attributes are for. So any attributes added in the engine which declare some behavioural change should be limited to those able to provide a tangible benefit which can't be achieved in userland. -Dave
[PHP-DEV] rounding integers
Hi all,
The "round" function supports rounding to significant digits before the
decimal point which can be very helpful
but unfortunately it's handling everything as floating point numbers
which in the end can lead to inaccurate results.
printf("%d\n", round(987654321098765432, -1) // 987654321098765440
instead of 987654321098765430
To be fair it's also documented as such:
> round — Rounds a float
round(int|float $num, int $precision = 0, int $mode =
PHP_ROUND_HALF_UP): float
I would like to propose to change this function to keep the given type
and proper handle integers as well:
> round — Rounds a number
/** @template T of int|float */
round(T $num, int $precision = 0, int $mode = PHP_ROUND_HALF_UP): T
Do you think this could be an acceptable BC-break or should this be a
different function?
Thanks,
Marc
