[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:123 jorbin]:
 > If speed is going to be used as an argument towards this, we need
 something that demonstrates it.

 It is too early to run any benchmarks. Conversion has barely started,
 which will only lay the groundwork. Right now, there's a large chance that
 the loading with the autoloader will include the exact same set of classes
 as before. Once the conversion to an autoloader has been made, there's
 lots of optimization opportunities. Only after doing these will we see an
 improvement. Also, some scenarios like AJAX calls will offer more
 optmization potential then others.

 Replying to [comment:124 azaozz]:
 > Having "pluggable" classes in WordPress is out of the question.

 As most objects are passed around through globals, you already have
 "pluggable" objects either way.

 > @schlessera, @flixos90, @flixos90 not sure how well you know the
 WordPress codebase but there is a thing called "pluggable.php". As far as
 I know this is a left-over from forking b2 14 years ago that wasn't
 fixed/removed in time. This is probably the worst architectural decision
 ever. Why would you want to extend it? :)

 Yes, I know that "thing" and also commented on it. There's a fundamental
 difference here. The original "pluggable.php" was a mechanism where
 developers '''were meant to replace''' core parts, and it was badly
 designed to fulfil that purpose. Here, we developers '''are not meant to
 replace''' classes, and the possibility to do so nevertheless is just part
 of the language. You can't make the fact go away that bad coders will do
 bad things. If they intend to replace a class, they will do it, with or
 without autoloader.

 > I agree. Autoloading is great for classes. After a quick look through
 the code, about 80-100 of the 200 classes will always be loaded, and half
 of the rest would never be loaded together. So currently autoloading will
 affect maybe about 5% of the code. This is still good, that percent will
 increase in the future.

 Yes, this is the state of the current code. As there has not been an
 autoloader so far, the code is not optimized to make effective use of an
 autoloader. This is something that can be easily changed, though.

 > Not true. Plugins cannot replace any of the `required` classes.

 They can replace pretty much any object that is stored in a global
 variable. They can overwrite Core files (on most systems). They can
 replace a lot of core functionality through hooks. And I'm sure they'll
 find even more creative ways to break stuff I wouldn't even think about. I
 agree that this is a problem that needs to be dealt with, but I don't see
 this as an argument for or against an autoloader. The issue of replacing
 core parts would ideally be dealt with by accepting that this is
 unavoidable, providing interfaces, and thus having contracts in place,
 which still allow plugins to replace parts, but define what behavior they
 need to adhere to to not break stuff.

 > Totally agree. As far as I see the way to proceed here is:
 > - Make an experimental branch where all this can be tested and cleaned
 up before merging in core.
 > - Find a way to "lock down" core classes so they cannot be replaced by
 plugins. Think of this like having the `final` keyword in class
 definitions. One possible way would be to have a custom autoloader that
 has a list of the core classes and doesn't do `class_exists()` before
 loading any of them (and keeps some sort of state to test if they are
 already loaded).

 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. If you want to lock down core classes, you need to let the code
 using them make a check to make sure they got the right one. You can only
 check the usage, not the creation. But I don't recommend this, it will
 only cause lots of trouble and horrible code, while still not being
 bullet-proof.

 Replying to [comment:127 jorbin]:
 > Replying to [comment:125 afragen]:
 > > PHP 5.3 and namespacing sure seems like it would negate many of these
 potential issues.
 > How?  Even with namespaces, a plugin could still include it's own
 version with whatever namespace we end up using.
 Yes, namespaces would not prevent explicit overriding of anything. But
 they would prevent accidental collisions, and that's what we should worry
 about.

 Replying to [comment:129 iamfriendly]:
 > I'm not sure it's about catching/preventing all of the instances of
 someone doing it wrong. It's about setting a precedent and, possibly more
 importantly, setting expectations.

 You set expectations through documentation, doc blocks, typehints and
 asserts, not by avoiding language constructs.

 > Ultimately, this has a potential to break a lot of things, very quickly
 and very badly. (Please note I am very pro this change, I'm just urging an
 abundance of caution). One mis-step can lead to developers going down a
 winding path without us really realising it. This can end badly for the
 user. (See the shortcodes API changes last year, which admittedly was a
 necessary change to a feature and this is more architectural, but the
 point stands).

 The shortcodes API change broke the actual user content in the databases
 of the users. I don't think you can compare a code change that will have
 an incidence on future plugins with a change that breaks ten year old
 existing content. But I agree that cautionary tales are always there for a
 reason...

 > There are currently many ways to override core pieces (in a
 doing_it_wrong fashion) but that doesn't mean we should simply ignore that
 and give developers another chance to shoot themselves and their users in
 the foot.

 How about giving them another chance to produce better code? Those who
 intend to produce quality code will be grateful for an autoloader.

 > I'm +1 for the addition of a branch which would allow us to really
 hammer this and see what breaks in a lot of scenarios. It (probably) means
 a slower inclusion into core, but it sure as heck gives us a real chance
 to see what's happening and also can give developers a chance to test and
 test again. It also gives us a way to compare and contrast items like
 speed and memory usage.

 I don't know enough about workflow/deployment internals to comment on
 this. But I sure was shocked to read that trunk is deployed as is on .org,
 so a branch is probably the safer bet.

 > I truly believe that, when merged, this will be one of the biggest, most
 positive changes to WP in a long time. I'm so glad we're having this
 conversation and hashing out all of the ways we can get this done, to get
 it right.

 Yes, once the autoloader is in and we start optimizing the bootstrapping
 process to make use of it, WordPress will make huge strides.

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