[wp-trac] [WordPress Trac] #49628: Add is_post_type_viewable filter

[WordPress Trac]

#49628: Add is_post_type_viewable filter
---------------------------------------------+-----------------------------
 Reporter:  powerbuoy                        |       Owner:  hellofromTonya
     Type:  feature request                  |      Status:  reopened
 Priority:  normal                           |   Milestone:  5.9
Component:  Posts, Post Types                |     Version:  5.3.2
 Severity:  normal                           |  Resolution:
 Keywords:  has-patch needs-dev-note commit  |     Focuses:  administration
---------------------------------------------+-----------------------------

Comment (by Cybr):

 Thank you for following up. I believe the welcome change from comment:18
 helps with performance greatly. However, I am still not convinced it's the
 right way forward. I know WP 5.9 is imminent, so I ask for forgiveness for
 taking time away from other matters in need of attention.

 First, I'd like to ask: "Should we make WordPress strictly typed? And if
 so, could we do it gradually, thus inconsistently?"
 I think "no" and "please do not."

 My goal is to prevent this tactic from becoming a strategy: PHP is not a
 strictly typed language, and it shall never become one. Whoever is echoing
 that postulation should stop.

 > If this trend continues, it's reasonable to leap forward to where type
 casting non-scalars could also follow that trend.

 I doubt it will. PHP's
 [https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg RFC for
 8.1 is only about nullable], which I believe will resolve internally as
 void, in turn removing a strict check ("is a parameter not inputted **or**
 is it `null`?"), improving performance. Even if we will, we're not there
 yet; let's work with the facts we know: We're computer scientists, after
 all.

 PHP went from a weakly typed, slow, and buggy language to a dynamically
 typed, fast, and reliable language. Facing HHVM/Hack, the PHP Group began
 its quest for performance, making them rethink how to model PHP's internal
 structure. In this, they found that the overhead of **type juggling is
 inefficient** and it made both their and userland's **debugging process
 difficult**.

 1. [https://wiki.php.net/rfc/typecheckingstrictandweak Why is strict type
 checking problematic?]
 2. [https://wiki.php.net/rfc/scalar_type_hints_v5#background_and_rationale
 Background and Rationale (with introducing scalar type checking).]

 For example, `implode()` could take its parameters either way -- now, its
 order is strict. In PHP 7.4, they started **warning** userland; from PHP
 8.0 thenceforth, they **block its mixed usage with a fatal error**
 ([https://3v4l.org/J02FF see it in action]).
 [https://wiki.php.net/rfc/deprecations_php_7_4#implode_parameter_order_mix
 Their RFC states] this change was necessary for the function was
 inconsistent, and it didn't help their move towards strict type checking
 internally that improves the aforementioned inefficiencies and debugging
 processes.

 However, with this ticket's proposed patch, **there is no warning nor
 error** to the filter's user: It simply casts an incorrect return type of
 the filter to a different type and value, but then inconsistent with how
 PHP would juggle. PHP developers expect type juggling to go in
 [https://www.php.net/manual/en/types.comparisons.php a specific
 direction], but with this patch, when the developer doesn't abide by the
 strictly typed documentation they ought to follow (which we shouldn't
 expect from juniors), they'll find (after hours of debugging) that their
 weakly inputted `1|'1'|['1'] == true` unexpectedly became a strictly
 returned `false`.

 Please keep in mind that PHP internally (them) is not PHP userland (us).
 So, just because PHP is trending towards becoming strict-typed for native
 functions, it doesn't mean PHP will start bulldozing dynamically typed
 code that utilizes it. In fact, they are proud of managing a dynamically
 typed language, as shown in the first two links I enumerated above.

 I believe it is not Core's duty to handhold developers who think sending
 an incorrectly typed value is acceptable. I beg you not to mangle
 unexpected variables from on-server developer APIs. It makes onboarding
 difficult, bloats the code to no extend, and it makes WordPress painfully
 slow. Microseconds quickly add up to milliseconds, and even 5 milliseconds
 are noticeable to humans.

 I also ask you to change your perspective of PHP. **PHP userland is not
 PHP's backend**, and we can exploit that beautifully. Manifest typing is
 not cast upon us, and I doubt it ever will; the defenses placed in this
 patch act as though it did. Those are more obvious in comment:11 vs.
 comment:18 (ultimately, they act the same).

 > In the future, type safe filters will come to Core (maybe in 6.0). When
 it does, this code can be safely replaced with it.

 #51525 is an excellent proposal for plugins and theme developers that
 forward filter values to strictly typed functions. However, I am well on
 my way to removing all type-declarations from my plugins. The reason is
 that **Zend Engine is not optimized for this**; it adds
 [https://3v4l.org/JVmbv ~5% function overhead + ~4% per variable]. IIRC,
 OpCache was promised to check for types-declarations in the future;
 however, the large majority of WordPress websites do not have OpCache
 enabled or have it misconfigured by their host.

 I think my story boils down to that we should:
 1. handle variables strictly when the type is implied (`'hello' ====
 $user_var`);
 1. handle variables weakly of boolean type (`$act = ! $user_var` or `if (
 $user_var )`);
 1. cast when when makes sense (`42 === (int) $user_var`) (PHP can emit
 conversion warnings, good! Less work for us.);
 1. cast for filters `($thing = (string) apply_filters())` (PHP can emit
 conversion warnings, good! Less work for us.);
 1. cast for return types `return (bool) $user_var`.
 1. only emit deprecation notices when behavior changes from earlier WP
 versions.

 I also believe that only if WordPress should ever become strictly typed
 should we check filters and functions' types strictly. We're already
 facing issues with `array` vs. `iterable`; let's not pile up.

 Please reconsider. I apologize for this long post.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49628#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform