[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:210 MikeSchinkel]:
 > Replying to [comment:207 schlessera]:
 > '''Generating classmaps is trivial.'''  My ~50 line classmap generator
 proof-of-concept that was included in my huge patch illustrates this.
 > So we can please refrain from using ''"Composer can generate a
 classmap"'' as a reason to use Compser and instead move on to focus on any
 other potential benefits Composer can provide that I am evidently missing?

 Well, you went ahead and renamed all of the class files just to make this
 possible (or better: to make coding your generator trivial).

 > But not without having to using `is_file()` a lot. Or are you suggesting
 that we go ahead and accept that it will '''always''' be classmap based?

 You can use whatever you want. The generated autoloader "is one or more
 arbitrary PHP file(s) that we let it generate". Whether you want to have
 `is_file()` or not, whether you want to have unicorn ASCIIs in it, all
 possible!

 > My statement about staleness is now moot since nobody has taken any
 action on it.  So I have decide to move forward with a much more
 incremental approach, hence my numerous comments and additional planned
 comments today.

 Yes, exactly, but that is a very obvious and logical result. We are
 talking about a major paradigm shift here, this won't be done in a handful
 of days...

 > So that seems to me to be a very small benefit for all the intensity of
 debate.  Generating a classmap is almost trivial, as I have demonstrated.

 No, you demonstrated the contrary. You needed to refactor the entire
 codebase to get your generation working and your update went stale and
 useless in a matter of days.

 > But the autoloader generated by Composer will need to be modified as as
 Ryan McCue
 [https://core.trac.wordpress.org/ticket/36335?replyto=207#comment:180
 points out].  Thus we really get no ''"it just works"'' benefit from using
 the Composer autoloader and we get the overhead that it generates too.

 No, we modify the generator to generate the exact autoloader we need. That
 work is already done, btw (or at least the parts we could already agree
 on): [https://github.com/staylor/develop.wordpress/pull/1]

 > Then why don't we just debate the specific pros and cons of naming
 conventions -- as I was proposing we debate -- instead of getting back on
 the Composer soapbox right now?

 Because the ticket is about the autoloader, not about the coding
 standards.

 > One of the benefits of having files named for their class is that it
 makes it performant to load the classmap dynamically, as would likely be
 the case for files in `/wp-content/`.  Being able to scan a directory and
 grab the filenames as classnames means their is no potential breaking
 ambiguity in the conversion of the classname.
 > That said, I don't consider the file naming part critical, just a nice-
 to-have I would prefer that we adopt.

 Yes, totally agree, but completely irrelevant and unnecessary right now.
 We can generate whatever autoloader we need.

 > '''What I do consider critical is that we stop having circular debates
 and move things forward''' by finding things we can work on that do not
 require resolving the Composer debate, and that get us closer to seeing an
 autoloader included, no matter which autoloader it is.

 We were already moving forward, and most of the work is done already in
 the GitHub repo for the feature project:
 [https://github.com/staylor/develop.wordpress/tree/autoloader] . People
 agreed that it is too early to use Composer as a dependency manager, but
 they also agreed to use it as a build-time tool to simplify building an
 autoloader and keeping everything in sync. This is done in a feature
 project.

 > I think you keep saying this has an advantage but from my vista is seems
 all those proposed advantages have turned out to not be real advantages.
 If the main benefit is to save time then in the time we've debated this we
 could do that work you are trying to bypass three times over, and do a
 much better job.

 We are actively working on this, in the GitHub repo. This was decided in a
 Slack meeting.

 > But even if we could, why work with a tool that writes code -- a tool
 that you have to work to tweak -- when the code is trivial to write by
 hand?

 Because you end up with a stale autoloader that does not notice that
 classes have changed.

 > As an aside, you cannot generate this '''exact same''' autoloader with
 Composer.  But I digress.
 Yes, I can. Composer passes a list of classes, you then run it through
 whatever you want to generate a PHP file. Heck, you could even generate an
 animated GIF of your classes if you so want...

 > '''And I don't see how Composer is preferable either, so let us first
 focus on what we can move forward, okay?'''

 Yes, I'll just stop discussing here and continue working on the feature
 project. If you still want to try persuading people to move to something
 else, I'm fine with it, but I will (try to) not proceed further with this
 specific discussion.

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