Re: [PHP-DEV] Re: Introducing 2 new modes to round function
On 8/31/23 01:16, Jorg Sowa wrote: > Hello everyone, > As I am not sure what I should next I decided to follow the formal way and > I created the RFC for the change. I will start voting soon. Please let me > know if you have any suggestions. > > RFC under discussion: > https://wiki.php.net/rfc/new_rounding_modes_to_round_function > Hey Jorg You should announce the start of the discussion in a new email thread instead of reusing your old one. The subject should be something like "[RFC] [Discussion] Add 4 new rounding modes to round() function". This is done for maximal visibility. Also, I believe the link for "PHP_ROUND_CEILING" is wrong in your RFC. Kind regards Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Introducing 2 new modes to round function
Hello everyone, As I am not sure what I should next I decided to follow the formal way and I created the RFC for the change. I will start voting soon. Please let me know if you have any suggestions. RFC under discussion: https://wiki.php.net/rfc/new_rounding_modes_to_round_function
Re: [PHP-DEV] Casing of acronyms in class and method names
On Wed, Aug 30, 2023 at 1:44 PM Tim Düsterhus wrote: > Hi > > after suggesting the use of ucfirst(strtolower(...)) casing for acronyms > within a classname of a draft RFC, I was made aware of previous class > naming RFC (June 2017) that required the use of PascalCase for class > names, with the exception of acronyms which must be completely uppercased: > > [...] > 2. It decreases readability. > > Especially if multiple acronyms follow each other. One example is the > PCGOneseq128XSLRR64 mentioned above: It's not clear that XSL > (XorShiftLow) and RR (RandomlyRotate) are two different acronyms. > > Likewise PDOODBC is much harder to parse than PdoOdbc. > > Another example might be JavaScript's XMLHttpRequest which incidentally > mixes both variants. According to the class naming RFC it would need to > be called XMLHTTPRequest, resulting in 8 consecutive uppercase characters. > Thanks for bringing this up as readability is indeed an issue for me with all caps acronyms. I would much prefer Acronyms to be treated as words as this is how most people seem to use them anyway.
[PHP-DEV] Casing of acronyms in class and method names
Hi after suggesting the use of ucfirst(strtolower(...)) casing for acronyms within a classname of a draft RFC, I was made aware of previous class naming RFC (June 2017) that required the use of PascalCase for class names, with the exception of acronyms which must be completely uppercased: https://wiki.php.net/rfc/class-naming I'd like to propose to revisit this earlier decision for the following reasons. Before writing an RFC I'd like have some pre-discussion to gauge opinions. 1. It is not consistently applied: a) As an example ext/json has 'JsonException' which should've been JSONException according to the RFC's results. In fact JsonException's RFC was created just 3 months (!) after the class naming RFC in September 2017: https://wiki.php.net/rfc/json_throw_on_error b) Another example is ext/curl which has both 'CurlHandle' and 'CURLFile'. CURLFile predates the RFC, but there's also CURLStringFile which was added in PHP 8.1 and likely followed CURLFile's naming for consistency, but violating the RFC and being inconsistent with CurlHandle. c) ext/random's Random\Engine\PcgOneseq128XslRr64 would've needed to be called Random\Engine\PCGOneseq128XSLRR64 according to the class naming RFC. d) The accepted, but not yet implemented, "PDO driver specific sub-classes" RFC uses Pdo, e.g. PdoOdbc instead of PDOODBC: https://wiki.php.net/rfc/pdo_driver_specific_subclasses 2. It decreases readability. Especially if multiple acronyms follow each other. One example is the PCGOneseq128XSLRR64 mentioned above: It's not clear that XSL (XorShiftLow) and RR (RandomlyRotate) are two different acronyms. Likewise PDOODBC is much harder to parse than PdoOdbc. Another example might be JavaScript's XMLHttpRequest which incidentally mixes both variants. According to the class naming RFC it would need to be called XMLHTTPRequest, resulting in 8 consecutive uppercase characters. 3. Several commonly used userland libraries make a different choice. - Symfony's HttpFoundation: https://github.com/symfony/symfony/tree/6.4/src/Symfony/Component/HttpFoundation - Symfony's CssSelector: https://github.com/symfony/symfony/tree/6.4/src/Symfony/Component/CssSelector - Laravel's HtmlString: https://github.com/laravel/framework/blob/10.x/src/Illuminate/Support/HtmlString.php - PSR-7: https://www.php-fig.org/psr/psr-7/ - PSR-18: https://www.php-fig.org/psr/psr-18/ - ramsey/uuid: https://github.com/ramsey/uuid/tree/4.x/src - Flysystem is a little inconsistent, but has 'Ftp': https://github.com/thephpleague/flysystem/tree/3.x/src/Ftp - PHPUnit is a little inconsistent, but has 'Xml' and 'Json': https://github.com/sebastianbergmann/phpunit/tree/main/src/Util - Doctrine is also a little inconsistent, but has 'Dsn' and 'Sql' (but also 'SQL'): https://github.com/doctrine/dbal/tree/3.6.x/src/Schema/Visitor and https://github.com/doctrine/dbal/blob/3.6.x/src/Tools/DsnParser.php Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Apply strict_types to internal functions
On Wed, Aug 30, 2023 at 7:14 AM Saki Takamachi wrote: > I accidentally wrote the name in Japanese and it looks weird, so I'll > resend it, sorry. > > I also skimmed over past discussions. > > I've found that having full control over `strict_types` globally is not a > good idea. This is because it can break the behavior of many libraries, and > developers don't always respond appropriately to this fix. > > So I came up with the following idea. > Allows a new value of 2 for strict_types. > > However, since magic numbers make the code difficult to read, I thought it > would be a good idea to also provide strings that can serve as constants > and aliases. > > This could provide new options to users while safely maintaining backwards > compatibility. > > example: > ``` > // weak > declare(strict_types=0); > declare(strict_types='weak'); > declare(strict_types=STRICT_TYPE_MODE_WEAK); > > // strict > declare(strict_types=1); > declare(strict_types='strict'); > declare(strict_types=STRICT_TYPE_MODE_STRICT); > > // strict with internal func > declare(strict_types=2); > declare(strict_types='strict_with_internal_func'); > declare(strict_types=STRICT_TYPE_MODE_WITH_INTERNAL_FUNC); > ``` > > I need more time to come up with a better name. > > Saki > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > I'm not entirely sure if this is 100% related, but it seems to be. If you don't declare "strict_types" and pass a Stringable instance as the first argument to json_decode, it works as expected [1]. On the other hand, when you declare "strict_types" and pass a Stringable instance as the first argument to json_decode, it fails [2]. Fatal error: Uncaught TypeError: json_decode(): Argument #1 ($json) must be > of type string, strcls given > [1] https://3v4l.org/TXAUi [2] https://3v4l.org/uEhbM -- Atenciosamente, Flávio Heleno
Re: [PHP-DEV] Apply strict_types to internal functions
I accidentally wrote the name in Japanese and it looks weird, so I'll resend it, sorry. I also skimmed over past discussions. I've found that having full control over `strict_types` globally is not a good idea. This is because it can break the behavior of many libraries, and developers don't always respond appropriately to this fix. So I came up with the following idea. Allows a new value of 2 for strict_types. However, since magic numbers make the code difficult to read, I thought it would be a good idea to also provide strings that can serve as constants and aliases. This could provide new options to users while safely maintaining backwards compatibility. example: ``` // weak declare(strict_types=0); declare(strict_types='weak'); declare(strict_types=STRICT_TYPE_MODE_WEAK); // strict declare(strict_types=1); declare(strict_types='strict'); declare(strict_types=STRICT_TYPE_MODE_STRICT); // strict with internal func declare(strict_types=2); declare(strict_types='strict_with_internal_func'); declare(strict_types=STRICT_TYPE_MODE_WITH_INTERNAL_FUNC); ``` I need more time to come up with a better name. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Security Bugs on GitHub
Hi On 8/30/23 11:05, Derick Rethans wrote: However, our old bug system still accepts them. I have just created a PR to change that: https://github.com/php/web-bugs/pull/116/files Pending reviews and/or comments, I am wanting to merge this in the next week or so. There's already https://github.com/php/web-bugs/pull/115. See also: https://news-web.php.net/php.internals/120672 Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Security Bugs on GitHub
Hi, In the past few months we have been trialing using GitHub security advisories for security issues: https://github.com/php/php-src/security/advisories?state=published However, our old bug system still accepts them. I have just created a PR to change that: https://github.com/php/web-bugs/pull/116/files Pending reviews and/or comments, I am wanting to merge this in the next week or so. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
