![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Changes between Version 1 and Version 2 of Ticket #57213, comment 11
- Timestamp:
- 06/02/2025 01:10:23 AM (15 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #57213, comment 11
v1 v2 1 1 Duplicate of #58831. 2 2 3 Funny to see that here people were discussing on a ton of things, including the performance implications and meanwhile [https://core.trac.wordpress.org/ticket/58831#comment:38 this was merged] under the hood and no one even noticed [56511] (and not even with static casting as proposed by @mukesh27), and obviously not with unit-tests.3 Funny to see that here people were discussing on a ton of things, including the performance implications and meanwhile [https://core.trac.wordpress.org/ticket/58831#comment:38 this was merged] under the hood and no one even noticed [56511] (and not even with static casting as proposed by @mukesh27), and obviously not with unit-tests. 4 4 5 By the way, @johnbillion, just as a curiosity, on the paper a type cast with a `===` can't have an impact compared with a regular comparison. For all scenarios where type conversion happens the complexity is going tobe the same, except for strings, where casting from `string` to `int` (in case it's ever cast) will have a constant complexity, while a classic comparison will need to ultimately do the same. So I doubt that performance testing was required at all, and I doubt that these changes were required at all (other than aesthetic purposes).5 By the way, @johnbillion, just as a curiosity, on the paper a type cast with a `===` can't have an impact compared with a regular comparison. For all scenarios where type conversion happens the complexity will be the same, except for strings, where casting from `string` to `int` (in case it's ever cast) will have a constant complexity, while a classic comparison will need to ultimately do the same. So I doubt that performance testing was required at all, and I doubt that these changes were required at all (other than aesthetic purposes). 6 6 7 7 Anyway, time to close this as it has been already fixed, and I wonder if there is a risk that `$the_['accepted_args']` could be a noninteger (which shouldn't). 8 8 9 For more info I've tried this simple code 10 11 {{{ 12 function hide_admin_bar() { 13 return false; 14 } 15 16 add_filter('show_admin_bar', 'hide_admin_bar', 10, '0'); 17 }}} 18 19 Just to showcase a string `accepted_args`, which theoretically should fail on the `0 ===` comparison, and it works! At some point, it appears that it's converted to 0 int… So, for some reason, this always worked for all cases with the simplest of the solutions :)
