gistfile1.txt

Ryan McCue [20:52]
So, I like the idea of using a tool (whether that's Composer or otherwise) to build classmaps

[20:53]
The thing is that introducing Composer is a pretty major step to take

[20:53]
Whether we do that or not, I want autoloading

[20:53]
So I want to introduce the stuff I had in my patch, ​*but*​:

[20:54]
I want to eliminate the classmap in core, in favour of making it consistent based on rules

[20:54]
At build-time, we can have classmaps for performance/etc, but the classmap in my code is intended to be temporary

[20:55]
My fear is that we're going to sit around arguing for Composer, and in the meantime, there's no autoloading at all

[20:56]
(Which is kind of already happening)

Gabor Javorszky [20:56]
is having a branch of wp that's exploratory where the main goal is to see whether composer can be implemented to it, and if so, how, a possibility?

[20:56]
because in that case all the people who are arguing for having composer would have something to do instead of doing nothing because "omg wp is not having composer"

[20:57]
and at the end the discussion would be about how to implement something instead of why

[20:57]
more concrete

Ryan McCue [20:57]
I think hooking Composer up to build the classmap would be pretty minimal, based on my experience with it

Alain Schlesser [20:57]
I understand that your classmap is temporary. However, a generated class map through Composer is just as temporary. Composer can not only generate this first temporary classmap, but also every single transition from that classmap, to partial/final strcutures, to PSR-4, and standardize/optimize every single of these transitions.
1

[20:58]
I see Composer in this context as just one of the dev tools used to automate the generation of assets.

[20:58]
It so happens that this asset is a PHP file, but that is irrelevant, it is a build-time step only.

Ryan McCue [20:58]
Right, but I've already written the temporary stuff, which we can ship today

[20:59]
The Composer stuff is both conceptually and logistically a reasonably large change

Alain Schlesser [20:59]
As did I with the Composer variant. But mine is ready for all that is to come too.

Ryan McCue [20:59]
(We'll need to change the WP core builds)

Alain Schlesser [20:59]
I don't have any issue with your particular code...

[20:59]
I have an issue with the concept of "brewing our own soup instead of using standards".

Ryan McCue [21:00]
(I think it's probably not likely we'll move to PSR-4, btw)

[21:00]
Generally speaking, I agree, but adding Composer is a pretty large decision that I can't make

Alain Schlesser [21:00]
In this particular case, there is no single advantage to be had by making something custom, and there's no excuse for not using the standard, as I see it.

Anton [21:00]
We've had a manual classmap in all Yoast plugins before and it was really a pain. (edited)

Alain Schlesser [21:00]
Composer can transparently create a PHP5.2 compatible autoloader.

Ryan McCue [21:00]
We're also not talking a large amount of code

[21:01]
This is like 100 lines or so

Anton [21:01]
Now we have composer if someone has any 'class does not exist' error we just say `composer du` and done.

Alain Schlesser [21:01]
This is like 100 mappings that need to be updated with every class change.

Ryan McCue [21:01]
Right, but that doesn't happen very often

[21:01]
Plus, once it's in place, we can start moving all the manual ones to match the rules instead

Alain Schlesser [21:01]
The whole point of the autoloader is because we want to make heavy changes to the class structure, no?

Ryan McCue [21:02]
No, I don't see it that way

Alain Schlesser [21:02]
Define the structure you plan to have in `composer.json`, move the class, done. (edited)

Ryan McCue [21:02]
My main goal is to move away from loading every class on every request

[21:02]
i.e. being able to tune the time/memory tradeoff

Alain Schlesser [21:03]
Yes, that's the basic premise of an autoloader, which we will benefit from no matter what autoloader is used.

Ryan McCue [21:03]
Sure :slightly_smiling_face:

Alain Schlesser [21:03]
This could just as well be done without an autoloader, but would require manual updating (just like a custom classmap).

[21:03]
It would just be a hell of a lot of logic.

[21:04]
What you can't get without an autoloader is that you don't need to update the files mapping to the classes.

Gabor Javorszky [21:04]
we used manual `spl_autoload` in subscriptions in one place

Ryan McCue [21:05]
@schlessera: Any new classes would fit into the rules, it'd just be our legacy ones that don't

Gabor Javorszky [21:05]
without autoloader there's no way I could wedge loading of the class between two uses of a filter. One prio is too late, the other is too early

Ryan McCue [21:06]
On the plus side, I'm going to commit my autoloader shim on #yolofriday, since that's uncontroversial :slightly_smiling_face:
1

Alain Schlesser [21:06]
That's why I also recommended splitting that into a new ticket. That's a good thing to have either way.

Ryan McCue [21:06]
Fundamentally though, the autoloader wouldn't have much churn, apart from ​*removing*​ the classmap configuration slowly

[21:07]
New classes would fit the rules, and we don't even add that many classes in releases

[21:07]
e.g. 4.5 added/changed 5 classes: https://developer.wordpress.org/reference/since/4.5.0/?post_type[]=wp-parser-class

Alain Schlesser [21:07]
I can't really estimate what the number of changes would be, but I bet that there would be bugs where people forgot to update the classmap.

Ryan McCue [21:08]
4.4 added/changed 10, and all of them fit the rules: https://developer.wordpress.org/reference/since/4.4.0/?post_type[]=wp-parser-class

Alain Schlesser [21:08]
I think you can't compare past numbers though, as an autoloader would make changes easier and allow us to reconsider the layout as a whole. (edited)

Ryan McCue [21:08]
The only reason I even wrote a classmap there is because I didn't want the patch to be huge with the file moves at the same time

[21:08]
Right, but the coding standards aren't going to instantly change right now

[21:09]
Changing to PSR-4 would be a coding standards change

Alain Schlesser [21:09]
Yes.

Ryan McCue [21:10]
All I want is to set up the scaffolding to allow us to work on everything, not to change everything at once. :slightly_smiling_face:

Alain Schlesser [21:10]
I don't think a change to PSR-4 would be necessary, but it would be a great step towards interoperability with existing PHP libraries/frameworks.

Ryan McCue [21:11]
I don't see that as a huge problem, but more importantly, I think that's a separate discussion to have

[21:11]
I just want ​_some_​ autoloading :slightly_smiling_face:

[21:11]
The quicker we can move, the quicker we can start looking at decisions around the actual loading of classes

Alain Schlesser [21:13]
Hehe. You have a lot more experience within WP than I have, so I cannot judge whether something would even be possible or accepted by the Core team or not. I can only tell you how I would deal with the issue. I think that there are large steps that need to be taken sometimes, because the smaller steps will never bring you to your final goal.
If your final goal is "autoloading in WP", you're probably right about everything. If your final goal is "modern PHP development in WP" though, I think a small step will hinder the end goal.

Ryan McCue [21:13]
Implementing a minimal autoloader doesn't stop us from using Composer later :slightly_smiling_face:

Anton [21:14]
Well it might if we decide the final autoloading style with this patch

Alain Schlesser [21:14]
No, just as implementing a minimal db abstraction (wpdb) will not hinder us from having interchangeable DB backends later on :wink:

Ryan McCue [21:15]
@atimmer: My patch only describes WP as it is right now, it makes no real judgements about how it should be

[21:15]
But in any case, there's nothing stopping us later ripping it out to replace it with an automatic Composer-generated one

[21:16]
The only thing we'd lock ourselves down to is supporting the autoloader classes in the future, but those are still a useful API even if WP has an autogenerated classmap (edited)

Alain Schlesser [21:16]
Your patch, when committed, has changed WP as it is now into a WP as it is now with an autoloader not using Composer. I might be wrong, but it would probably mean that at some point, Composer is at odds with the custom implementation. And then it's too late (see wpdb). (edited)

Anton [21:16]
That is also my concern (edited)

Ryan McCue [21:17]
I'm unsure how that would be at odds?

Alain Schlesser [21:23]
My past experience leads me to believe that nothing which enters WP core will leave again. So, my guess would be that the interface you'll commit will be modified, extended, etc... to make way for every imaginable scenario that goes beyond "just load the legacy classes".
In my imagination, this will result in an autoloader that has the same relationship to Composer, than `wpdb` has to something like Doctrine. The autoloader will get convoluted and stay stuck in legacy land, while the rest of the PHP world will move on.

[21:23]
Wow, that's a very negative view, maybe I didn't get enough coffee today yet...

Ryan McCue [21:24]
Just so we're clear, the interface in my patch was only temporary, I only want the implementation classes in core :slightly_smiling_face:

[21:24]
And yes, anything that goes into core is going to need to be supported forever, but this is a minimal amount to actually support

Alain Schlesser [21:24]
Temporary + absolute backwards compatibility spells disaster... :wink:

Ryan McCue [21:24]
I think we may actually have more problems with the Composer one

[21:24]
Wait until people start using the `Composer_Autoload_<random>` class directly :slightly_smiling_face:

Coen Jacobs [21:25]
Mark it `@internal`, nobody uses `WP_List_Table` :wink:
1

Ryan McCue [21:25]
Oh, no, I meant the interface was temporary ​_pre-commit_​

Alain Schlesser [21:25]
That's not an issue with Composer, that's like people deleting their database tables...

Ryan McCue [21:25]
The interface was just so I could generate my nice little HTML table for local testing

[21:25]
https://core.trac.wordpress.org/attachment/ticket/36335/classes-real.php is what I was proposing

Coen Jacobs [21:26]
@rmccue: What are the issues you see with the Composer autoloader?

Alain Schlesser [21:26]
Well, I would guess that chances are much higher that people mess with these `WP_Autoload_*` classes, than with the Composer file...

Ryan McCue [21:26]
@coenjacobs: Introducing Composer into the build stages is a massive change conceptually

[21:27]
It would need discussion by the leads at the least

Gabor Javorszky [21:27]
who uses the build stages?

Ryan McCue [21:27]
@javorszky: The releases, `core.svn.wordpress.org`, github.com/WordPress/WordPress

Coen Jacobs [21:27]
Oh yes, not arguing about that. I thought you were talking about technical implementation of the autoloader itself.

Gabor Javorszky [21:27]
right, but you have control over that environment

Ryan McCue [21:27]
I have no issues with the technical aspect of Composer's autoloaders

[21:27]
​*I*​ do not

Gabor Javorszky [21:28]
well, no, but there are a set number of finite people who do

[21:28]
and they're devs

Ryan McCue [21:28]
The WP meta team does, but again, that'd need sign-off by leads etc

[21:28]
It's not something we can ship quickly though

Gabor Javorszky [21:28]
so it's not like john doe's muffin blog will go down because he doesn't know how to use this

Ryan McCue [21:28]
My patch can go in this cycle, however :slightly_smiling_face:

[21:29]
@schlessera: And yeah, totally possible, but that's what you get when you introduce things into core.

[21:29]
Which is fine.

[21:29]
In a future release, we could switch core to Composer-generated, and plugins can keep using those

[21:32]
(Note: we ​_could_​, I'm making no judgements on whether we ​_would_​ or ​_should_​) (edited)

Alain Schlesser [21:32]
> technical aspect of Composer's autoloaders
The actual file that will get generated can be completely customized.
You can have a `WordPressAutoloadGenerator extends BaseGenerator` that generates whatever you need.

Ryan McCue [21:32]
I'm aware of this, just FYI :slightly_smiling_face:

Alain Schlesser [21:33]
> and plugins can keep using those
They will, for better or for worse.

Ryan McCue [21:33]
I think that's absolutely fine.

[21:34]
Plugins should be able to use dynamic autoloaders.

[21:34]
Also, we're never going to have a perfect system, because the world is going to keep evolving.

[21:35]
If function (in namespaces) autoloading someday comes around, then the whole ecosystem will change again

[21:35]
It's possible that Composer gets superseded by something else as well.

[21:36]
That's why we shouldn't be afraid to change as needed. Implementing something today doesn't mean we can't change in the future.
1

Coen Jacobs [21:36]
That’s not an argument to not doing it the Composer way, imho.

One big downside that I see to your patch @rmccue, is that you’re basically reinventing the wheel for autoloaders. Especially since you say that the actual autoloader is not going to be implemented in this release yet, why not invest the time to do it ‘properly’ via Composer (a tried a trusted autoloading solution)?

Ryan McCue [21:37]
Autoloaders are a pretty minimal piece of code, so I don't see that as an issue.

[21:37]
And it's not an argument against using Composer, it's an argument against trying to do everything at once

[21:37]
We ​*have*​ to be able to evolve

Coen Jacobs [21:38]
Still, reinventing something already exists and is used by millions of people. Also, in terms of code, yes, the autoloader is minimal. But not in terms of footprint. I share the concerns raised earlier that this is going to become something that WordPress sticks to, just because it is there and this will block the implementation of a Composer autoloader.

[21:38]
Implementing Composer autoloaders now (in whatever release we want) doesn’t stop us from evolving.

Ryan McCue [21:38]
I disagree that it will block Composer

[21:39]
The issue as I see it is that waiting for Composer is going to mean many more releases without autoloading

Coen Jacobs [21:39]
Yeah, I have that feeling as well :slightly_smiling_face:

[21:39]
But that’s not an argument in favour of doing it manually/reinventing right now, imho.

[21:40]
(not saying your patch isn’t good btw, this is a ​*big*​ step in the right direction, I’m just afraid of the longer term plans with this)

Ryan McCue [21:40]
I would agree that it's reinventing ​*if*​ it were a substantial piece of code

[21:40]
But we're talking 100 lines of code

Anton [21:40]
So the blocker of a class map generated by composer is wordpress.org can't generate the class map for `core.svn.wordpress.org`? (edited)

Ryan McCue [21:40]
WP reimplements plenty of other things, and probably always will (edited)

[21:41]
@atimmer: That is not the only blocker, but it's one of the pieces that would have to change

Coen Jacobs [21:41]
@rmccue: Yes, WordPress is famous for it’s inventions :wink:

Ryan McCue [21:41]
I'm a pragmatist, and realistically, there's no way that WP is adopting Composer any time in the next 5 release cycles
1

Alain Schlesser [21:42]
I guess some people see it as making the trade off between "one or two releases of hassles ​*without*​ an autoloader" vs "all the rest of the releases of hassles ​*with*​ an autoloader". (edited)

Ryan McCue [21:42]
We can ship autoloading right now, and then argue for Composer

Anton [21:42]
@rmccue: Which additional blockers do you know about? And I'm not talking about any dependency management using Composer, only using it as a tool to generate a class map.

Alain Schlesser [21:42]
What would be the argument for Composer then?

[21:42]
"Why use Composer, we already have a perfectly fine autolaoder"! :wink:
1

Ryan McCue [21:43]
@atimmer: It's a large conceptual hurdle that we'd need to introduce to a lot of people

[21:43]
It took WP a long time to start using Sass for CSS, and this is an order of magnitude larger conceptual change

[21:43]
@schlessera: If the only argument for using Composer is that it generates classmaps, I think the argument is pretty weak

Alain Schlesser [21:43]
You're already using Grunt, no? Just add it as a Grunt step that is run automatically. Or add it to `npm`. Or add it to...

Ryan McCue [21:44]
If I controlled everything, that ​_might_​ be possible, but I do not

Anton [21:44]
I don't think it that much of a conceptual hurdle, explaining `composer du` at the office is one of the easiest things to explain among other things we have to explain.

Ryan McCue [21:44]
The reality is that WP isn't adding Composer until the leads agree on it

Alain Schlesser [21:44]
And, this is only for Core developers, not for end-users!

Ryan McCue [21:44]
Which isn't happening any time soon, as far as I see

Coen Jacobs [21:45]
@rmccue: Devils advocate here, has a lead dev agreed upon your autoloader yet?

[21:45]
Do they even have to?

Ryan McCue [21:45]
I have good vibes from several, yes

Gabor Javorszky [21:45]
so why not just make a PR with composer autoloading in, and then show the leads: "here's wp with composer autoloader. Discuss" instead of letting them argue about the theoretics of it

Ryan McCue [21:46]
@coenjacobs: And also, they don't really have to, because introducing autoloading isn't a huge topic

Gabor Javorszky [21:46]
knowing the speed with which you write code, you probably could have done most of it while this conversation's been going on :slightly_smiling_face:

Alain Schlesser [21:46]
> It took WP a long time to start using Sass for CSS, and this is an order of magnitude larger conceptual change
Disagree, that would be like swapping out PHP with C#...

Ryan McCue [21:46]
@javorszky: Well, there's the argument of whether ​_I'd_​ want it as well :slightly_smiling_face:

Gabor Javorszky [21:47]
so if they don't really have to beacause it's not a huge topic, then what stops Composer from going in? because "agreement from leads" falls short

Ryan McCue [21:47]
Composer is a large conceptual change, because we're buying into a larger ecosystem by adding Composer

[21:47]
It's not ​_just_​ an autoloader generator tool :wink:

Coen Jacobs [21:48]
For WordPress it would be ​*just*​ a autoloader. Because it’s run during build time and nothing else.

Alain Schlesser [21:48]
WP is already part of that larger ecosystem, but it is more and more considered to be the foul player.

Gabor Javorszky [21:48]
but then because it's core devs only... ?

Ryan McCue [21:48]
@coenjacobs: To do so, we'd need to add a composer.json, which buys us in in at least some regards

Alain Schlesser [21:48]
`npm` is used too, right?
1

Gabor Javorszky [21:48]
I'd love to see WP getting closer to how things are done in the general industry without needing to reinvent everything "the WordPress way"
4

Alain Schlesser [21:49]
That's part of the `node.js` ecosystem. (edited)

Gabor Javorszky [21:49]
just because "WP powers 24% of the web"

Ryan McCue [21:49]
@schlessera: It sure is, and it took us a ​_long_​ time to introduce that

Gabor Javorszky [21:49]
I argue that it's not BECAUSE the WP way is good, but rather despite what the wp way is

Alain Schlesser [21:49]
So, using the `node.js` tool is fine, but using the `PHP` tool is not?

Ryan McCue [21:49]
@javorszky: I don't disagree, but it's also important to understand that WP does have its own philosophy and that's not going to change

Alain Schlesser [21:49]
Seems weird to me that that would be harder to understand.

Gabor Javorszky [21:50]
@rmccue: that doesn't mean that that philosophy is set in stone

Ryan McCue [21:50]
@javorszky: Sure, but it also doesn't mean it ​_should_​ change. (edited)

Gabor Javorszky [21:50]
and I am far removed from the core team's daily dealings, but it kind of feels like these decisions are based on a few people's "I don't like it" opinions

[21:50]
because the technical aspects keep getting debunked

Ryan McCue [21:51]
Sure, that's how most projects are developed.

[21:51]
That's just how WordPress works.

Alain Schlesser [21:51]
Well, @rmccue I think we can agree that the issues we're discussing don't have anything to do with your code per se... :smile:

Ryan McCue [21:51]
:slightly_smiling_face:

Gabor Javorszky [21:51]
yeah, but then WP core devs are now inadvertently custodians of 24% of the web

[21:51]
and I do not think that "I don't like it" has a place there

Ryan McCue [21:51]
The Composer discussion is an interesting one, but one I want to leave

Anton [21:51]
Nowhere is the WordPress philosophy does it say that we have to ignore the improvements in the PHP community. I think we can achieve the goals of the WordPress and still learn from the PHP community.

Coen Jacobs [21:51]
WordPress is not “most projects”, btw. That’s the difference for me.

Anton [21:52]
And be more interoperable with other PHP projects.

Alain Schlesser [21:52]
I still stand by my recommendation that using a custom autoloader is the wrong approach. But I'm unknown in the WP community, so my opinion is not worth much.

Ryan McCue [21:52]
I am concerned about autoloading right now, and there's nothing that precludes us from moving to Composer later, apart from a very minimal set of classes we need to support

Gabor Javorszky [21:52]
except the "we already have this, let's not use Composer, because the benefit we'd get is already in there, and we don't want an even bigger conceptual change with less benefit now"

[21:53]
but it's been raised before

Ryan McCue [21:53]
As I said, if the argument for Composer is just that it generates classmaps, that's a weak argument anyway

[21:53]
If we do introduce it, it'll simplify the workflow

[21:53]
Which is an argument that holds regardless

Alain Schlesser [21:53]
There are lots of arguments for Composer, but the autoloader would be the best entry ticket.

Gabor Javorszky [21:53]
so why not introduce it earlier rather than later, and do it in one fell swoop?

[21:53]
immediate benefit: autoloader

[21:54]
long term benefit: dep management of sorts without needing to introduce yetanotherthing

Ryan McCue [21:54]
Because that would be a ​*massive*​ change

Gabor Javorszky [21:54]
and have this conversation again

[21:54]
for... core devs

[21:54]
the end users wouldn't see much, would they?

Daniel [21:54]
@javorszky: there are a lot of nuances to the autoloader conversation I think you're missing

Gabor Javorszky [21:54]
@daniel: most probably, which is why I'm probing here

Daniel [21:54]
e.g. how does an end user resolve a dependency conflict?

Ryan McCue [21:54]
Potentially, but core devs are who you need to convince

Coen Jacobs [21:55]
@daniel: That has nothing to do with autoloading for core.

Ryan McCue [21:55]
I have my own personal opinions on dependencies via Composer, but I don't think those are relevant

Alain Schlesser [21:55]
> how does an end user resolve a dependency conflict?
We are not talking at all about dependency management here.

[21:55]
That's a different and much larger topic.

Daniel [21:55]
but you are, in the grander scheme of things

Ryan McCue [21:55]
As I see the landscape, the choice is between getting some amount of autoloading into core that plugins and themes can being using straight away, versus no autoloading for the forseeable future

[21:56]
Because as I see it, Composer just isn't getting adopted any time soon

[21:56]
Whatever your opinions on that, I think that's the reality

Gabor Javorszky [21:56]
okay, very basic question: why not just make use of PHP's own `spl_autoloader` thing?

Ryan McCue [21:56]
@javorszky: you mean `spl_autoload()` ?

Gabor Javorszky [21:56]
that

Alain Schlesser [21:56]
Well, to be honest, than I would personally prefer not having an autoloader in Core, so that I can be sure it won't mess with my business logic using Composer. :slightly_smiling_face:

Ryan McCue [21:56]
I'm unsure how core having autoloading would affect any of your code?

[21:57]
@javorszky: That uses the `include_path`, which doesn't contain any of the locations WP has classes

[21:57]
(It's a pretty crappy autoloader, really)

Gabor Javorszky [21:57]
you can specify the paths though

[21:57]
sure, some of the files would need to be renamed

Ryan McCue [21:58]
If you change `include_path`, sure

Alain Schlesser [21:58]
Autoloading is always PHP session wide. If you provide an API within Core that plugins can use to autoload their classes, and still not have namespaces, plugins will mess up big time.

Gabor Javorszky [21:58]
no, "if you can't find the class in include path, do this: `require_once 'yourownpath/ . $class . php`"

Ryan McCue [21:58]
@schlessera: The autoloaders have `file_exists` checks, so I don't believe it would break anything

[21:58]
Oh, hahahahaha, I forgot to write that

[21:58]
lolz

[21:58]
They ​*should*​ have them :slightly_smiling_face:

[21:59]
@javorszky: Then you've just written a custom autoloader?

Alain Schlesser [21:59]
The first class to appear in the code for PHP will get loaded, with no way to have any control over it.

Gabor Javorszky [21:59]
@rmccue: which is what you've done

Alain Schlesser [21:59]
Plugins can't even be set to a specific loading order right now.

Ryan McCue [21:59]
@javorszky: Right, but I'm not sure what your point is

[21:59]
@schlessera: That's no worse than currently.

Gabor Javorszky [21:59]
why reinvent the wheel

[22:00]
because there's a perfectly good and widely used and maintained thing that does this
1

Ryan McCue [22:00]
We're talking in circles :slightly_smiling_face:

Alain Schlesser [22:00]
Yes, it is. Right now, plugins without namespaces don't mess with autoloaders. (edited)

Gabor Javorszky [22:00]
I'm aware

Coen Jacobs [22:00]
Hey, why not just use Composer, @rmccue ?

Ryan McCue [22:00]
:neutral_face:

Coen Jacobs [22:00]
:wink:

Ryan McCue [22:00]
@schlessera: I do. :slightly_smiling_face:

[22:00]
PSR-0 exists :slightly_smiling_face:

[22:01]
(Don't worry, I write 5.5+ code for non-distributable code)

Alain Schlesser [22:01]
Yes, but I would assume that your skill level is a bit above that of the average WordPress developer. (edited)

Ryan McCue [22:01]
Sure, but I'm unsure how adding this to core would affect that at all

Alain Schlesser [22:01]
I don't want to bash any developers here, but let's be honest. Most plugins are cobbled together through online tutorials.

[22:02]
Well, there will be a tutorial: "How to use the Core autoloader."
2

Ryan McCue [22:02]
`while true; do curl stackoverflow.com/random > plugin.php; endwhile`

Alain Schlesser [22:02]
Yes, pretty much... :slightly_smiling_face:

Ryan McCue [22:02]
I'm unsure how tutorials are a problem

[22:03]
There are tutorials out there already talking about autoloading

Alain Schlesser [22:03]
autoloader + no_namespace + no_clue = problem.

Ryan McCue [22:03]
I'm also unsure how that would be a problem at all

Alain Schlesser [22:04]
Debugging autoloader issues is already complicated ​*with*​ namespaces. I honestly don't want to find out what it's like in the 5.2 world...

Ryan McCue [22:05]
The code I've written requires you to have a prefix, so I don't think that's an issue

Alain Schlesser [22:05]
Yes, as most people use their initials as prefix, that should be fine... :facepalm:

Ryan McCue [22:06]
Changing from prefixes to namespaces wouldn't fix that

[22:06]
You'd just have a `RM` namespace instead of an `RM_` prefix

[22:06]
In any case, I don't see how that would affect your code

Alain Schlesser [22:07]
No, but changing to a Composer autoloader that comes with documentation and recommended best practices out of the box probably would.

[22:07]
Changing code standards to require a proper vendor/package prefix probably would.

Ryan McCue [22:08]
If we merge my code, there's nothing stopping you from writing best practices for that :slightly_smiling_face:

[22:08]
Bonus: no one else has, so you'd be top of the list

Alain Schlesser [22:08]
A bit of preaching to the choir... ? :slightly_smiling_face:

Ryan McCue [22:09]
If your concern is people teaching other people how to use the autoloaders wrong, then you can beat them to the punch

Alain Schlesser [22:11]
The wrong ones will beat me in numbers... :wink:

Ryan McCue [22:11]
First mover advantage :slightly_smiling_face:

[22:11]
Plus, we can always write a make/core post that will naturally end up highly rated

[22:14]
Anyway, tl;dr: I want to move fast and make progress on core without getting blocked on convincing people we need Composer

[22:14]
I do not see any forward-compatibility issues :slightly_smiling_face:

Alain Schlesser [22:17]
Fair enough. I suppose I'm just too far removed from WordPress itself. I use it as the backend platform, but the actual development I'm doing is far from what you can see in Core.
I would love to get the two worlds to reunite, and when I see opportunities to help them to do so, I will gladly contribute.
But I'm not into the whole "politics" type of thing. If no one sees a need to get WP into ​*this*​ decade, so be it.

Ryan McCue [22:19]
I want to move forward, but I want to do it slowly and considered :slightly_smiling_face:

Alain Schlesser [22:19]
But you're already 10 years behind, would be time to accelerate the pace... :wink:

[22:20]
Before anyone gets offended by these remarks, I do exaggerate to get my point across.

Alain Schlesser [22:20]
often forgets that people take such remarks too seriously.

Ryan McCue [22:20]
Don't worry, I don't get offended easily :slightly_smiling_face:

[22:21]
After being in open source for most of my life, I have a pretty thick skin :stuck_out_tongue:

Alain Schlesser [22:21]
Open sourced nerve ends...? :slightly_smiling_face:

Ryan McCue [22:21]
haha

[22:23]
Anyway, I'd love to see thoughts on moving from autoloaders in core to Composer support on a new ticket, so we can hash that out on Trac

[22:23]
I don't think having an autoloader now blocks that, and it'd be nice to have a ticket for that

[22:25]
Gotta run, thanks for the discussion folks, good to hear thoughts :slightly_smiling_face:


----- June 2nd -----
Brett [00:04]
This isn’t necessarily #heavydev but was met with silence in #learntogether :slightly_smiling_face: What’s the best way to go about migrating all BuddyPress and bbPress data from a client’s old site to the new one we built for them?

Jeremy Ward [00:29]
Gah, completely missed the early morning autoloader chat. Yet again. I need to get up about 5 hours earlier.

[00:30]
Wouldn’t one of the benefits of using Composer for autoloading be that the class map it generates includes some kind of hash value in its naming scheme so that it virtually prevents namespace collisions?

[00:30]
I fully agree with @javorszky’s assessment that it’s a widely-used and supported platform, and with the other points about how WordPress is already using `npm`. I don’t understand the Core’s team hesitance to introduce it into the WP ecosystem.

[00:31]
Because, sure, even if you’re using it “just for autoloading”, you’re getting a widely-supported autoloader that should be theoretically easier to troubleshoot.

[00:31]
And you’re setting yourself up for the future benefits it provides.

[00:32]
Ryan, I know you don’t want to continue this conversation, so I won’t tag you (with apologies to Gabor), but you yourself said you wrote “a pretty crappy autoloader” (I haven’t looked at your patch and wouldn’t be qualified to judge it anyway) - so why not make a case for a tested one?

Alain Schlesser [00:33]
> class map it generates includes some kind of hash value in its naming scheme so that it virtually prevents namespace collisions?
That hash is only for the class map itself, not for the classes it autoloads. Otherwise, all dependent code would break, as the Classes being used would need to know about that hash.

Jeremy Ward [00:34]
Gotcha. Thanks for the clarification, @schlessera. I appreciate your presence here and advocacy for widely-used solutions.

Alain Schlesser [00:34]
> widely-used
This often comes with valid reasons...

Jeremy Ward [00:35]
If I’m understanding things correctly, it sounds like there are some classes in WP Core that are outside of the path where Composer might find them. Is that part of the hesitance? Couldn’t those classes be excluded from the autoloader still be included using an `include_once` or `require_once` statement to get them into the application? Or are there challenges with the order in which files load?

[00:36]
I’m just trying to get a better understanding about the opposition to using Composer, other than the fact that it would add a `composer.lock`, `composer.json`, and `package.json` file to the project.

Michael Beckwith [00:36]
doesn’t Composer heavily rely on namespaces? Perhaps something touched on in the discussion earlier that i haven’t read through

Jeremy Ward [00:36]
(But, again, `npm`)

Coen Jacobs [00:36]
@tw2113: No, class maps are perfectly capable of doing non-namespaces classes as well.

[00:36]
PSR-4 on the other hand is completely namespace based.

Jeremy Ward [00:36]
(n/m, I see Coen’s reply)

Michael Beckwith [00:37]
gotcha. no absolute need for namespaces removes friction

Coen Jacobs [00:37]
There is a package that does make the autoloader PHP 5.2 compatible as well, so should we want to go down that rabbit hole, we can.
1

Alain Schlesser [00:38]
> If I’m understanding things correctly, it sounds like there are some classes in WP Core that are outside of the path where Composer might find them. Is that part of the hesitance?
No, Composer can deal with any setup. In fact, I had pretty much the exact same classmap be generated automatically with 1 single line in `composer.json` (https://www.alainschlesser.com/adding-central-autoloader-wordpress/). (edited)

[00:38]
> and `package.json` file
No, that's for `npm`.

Jeremy Ward [00:39]
Gotcha. Seems like Jordi has really thought through a lot of these issues, then.

Alain Schlesser [00:39]
> doesn’t Composer heavily rely on namespaces?
Composer itself uses namespaces, but it doesn't care about them when generating the autoloader. There's also a PHP5.2 extension for it that produces PHP5.2 compatible autoloaders without namespaces.

[00:40]
Ah, @coenjacobs was faster...

Coen Jacobs [00:40]
Sorry :smile:

Michael Beckwith [00:40]
now how to prevent breaking things when package managers abandon things, or github issues

[00:40]
he was too busy worrying about his own baby here

Coen Jacobs [00:40]
Autoloaders have nothing to do with either GitHub or packages.

Alain Schlesser [00:41]
> Seems like Jordi has really thought through a lot of these issues, then.
No. The entire PHP community (minus WordPress) has.
2

Michael Beckwith [00:41]
it was a joke @coenjacobs :stuck_out_tongue:

Alain Schlesser [00:41]
It is really hard to find any serious PHP project now that doesn't use Composer, and it has been able to deal with any scenario you can think of.

Jeremy Ward [00:41]
And it now has a stable release.

Coen Jacobs [00:42]
The main problem WordPress has with Composer is that WordPress is entirely end user based. Composer is ​*not*​ an end user feature and end users will never have to be able to use it.

Alain Schlesser [00:42]
> And it now has a stable release.
Yes, after 5 years of development & testing.

Coen Jacobs [00:42]
For autoloaders that are generated on build process, that is fine.

[00:43]
But for dependencies and packages and what not more, I have no idea if that ever is going to land in WordPress core.

Alain Schlesser [00:43]
But end users might need to find out one day that their platform of choice is completely outdated because all of the developers have moved on.

Jeremy Ward [00:43]
I wonder if there’s something that we can do, as the rest of the non-core committing community, to make a case for the Core committers for why they should use it; ask them about their hesitance; and see if we can make a case for why the package would address those issues.

[00:43]
I wonder if one of their points of contention is our insistence that they use it.

Alain Schlesser [00:44]
Well, it's difficult to make a case, when the argument is: "No Composer."

Jeremy Ward [00:45]
I know. It’s politics as usual, but trying to hammer it home isn’t always the best approach. I would genuinely like to know what the real blockers are. But then, I’m still just a few years into this, so that’s probably naive to expect that we’d ever know.

Alain Schlesser [00:45]
All the pros are simply ignored, while the only con is : "Humm, nah, not now.".

Anu Gupta [00:45]
All the developers aren’t going to move on.

Coen Jacobs [00:45]
Really? I can name several that have already moved on.

Michael Beckwith [00:45]
the users focus over developers focus is always the hardest pill to swallow

Anu Gupta [00:45]
Several != all

Alain Schlesser [00:46]
No, but most of those that could make a positive impact. Why should they continue to struggle for years with an outdated platform that makes their life needlessly difficult.

Anu Gupta [00:46]
they don’t have to

[00:46]
No one is making them

Rahul Bansal [00:46]
> users focus over developers
I believe feel user should come first. But then things can be taken case-by-case

Alain Schlesser [00:46]
I think that any extreme is bad. "developer-only" just as well as "user-only".

Rahul Bansal [00:46]
Ya

[00:47]
Sometimes you can find a tradeoff

Alain Schlesser [00:47]
I understand why users should be considered a priority. But completely dismissing developers might end up costing most of these developers. And end users will not patch the security holes....

Coen Jacobs [00:48]
This debate has been going on for years now, not just today :slightly_smiling_face:

[00:48]
I hope something is gonna change, some day.

[00:48]
But I lost track of the how.

Alain Schlesser [00:48]
I'm a fresh member to the circus, so I still have some energy left... :wink:

[00:49]
But already now I am trying to make most of my code as platform-agnostic as I can. Because market share numbers don't really impress me, there's always a next big thing...

Coen Jacobs [00:49]
You all have fun figuring out a solution. :wink: