[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal

[WordPress Trac]

#36335: Next generation: core autoloader proposal
-----------------------------+------------------
 Reporter:  dnaber-de        |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  4.7
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------

Comment (by schlessera):

 Replying to [comment:137 azaozz]:
 > > The shortcodes API change broke the actual user content in the
 databases of the users.
 > No. The change broke the way some plugins use shortcodes. Shortcodes are
 placeholders. Nothing more. That breakage happened because these plugins
 misused the core functionality and used the shortcode API in an unintended
 and unsupported way, even introducing security problems in the process.

 I agree about the technical nuances. But the change was more user-facing
 than the autoloader one.

 > And that happened because the API was (and still is) too permissive.

 No, it happened because there just was no appropriate API for what both
 the plugin authors and users needed. Making stuff less permissive just
 pushes developers into "illegal" behavior.

 > I'm not sure how to make this easier to understand :) This is somewhat
 similar to using `private` in a class. Is there even one OOP app out there
 that instead of using `private` adds some documentation like "Please don't
 touch this from the outside. Thanks.". Why is there a `private` keyword
 anyway? :)

 Well, most of the time, they differentiate between `private` and
 `protected` to communicate intent. Sure, you can break the hell out of a
 `protected` property. But it's worse if you need to use hacks if there is
 no `protected` property you can reuse.

 > > That's not how an autoloader works. The autoloader does not do
 `class_exists()` because it will only get invoked if it doesn't yet. If
 the class has already been defined, the autoloader will not even be
 triggered.
 > What I meant is that one possible way of making this work would be to
 rewrite the logic that checks whether a class is already loaded, and add a
 whitelist of the core classes.
 Yes, but as I said, that is not how autoloading works. This "logic" is
 actual the PHP language itself calling the autoloader callback _after_ it
 noticed that a class is missing.

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