Customizer subclasses can be broken out and remain BC

[wonderboymusic]

The Customizer base class files can load their implementations at the bottom of the file via require_once(), instead of moving everything and then loading everything in a manifest.

The Customizer code can make sublime sense when you are looking at small implementations of the base classes by themselves, it is overwhelming to look at a multi-thousand-line file to debug a 100-line class.

I waited to think this through after #33413. Loading them like this should be a non-event, but will make the code infinitely more readable.

[wonderboymusic]

In 35383:

Customize: move WP_Customize_Setting subclasses to wp-includes/customize, they load in the exact same place.

See #34432.

[wonderboymusic]

In 35385:

Customize: move WP_Customize_Section subclasses to wp-includes/customize, they load in the exact same place.

See #34432.

[wonderboymusic]

In 35386:

Customize: move WP_Customize_Panel subclass to wp-includes/customize, it loads in the exact same place.

See #34432.

[wonderboymusic]

In 35389:

Customize: move WP_Customize_Control subclasses to wp-includes/customize, they load in the exact same place.

See #34432.

[azaozz]

I'm not sure this is a good idea. It adds more server i/o to load 27 files, so it is a bit worse for the users.

I suspect the idea of "one class per file" comes from languages that are compiled (C, C++, etc.) where the code is combined before execution. It doesn't make much sense in languages that use interpreter like PHP where each file is "loaded" on every run. Especially when many of the files have only 2-3 lines of code in them.

From "coding" point of view, IMHO having many files with just few lines of code makes it harder to edit anything in them as it requires you to have 15-20 files opened at the same time and switching between them is disorienting after a while. Grouping similar (small/short) classes in one file will probably be better and makes changing them easier.

I've been having some doubts about #33413 too. The reason for splitting there was this part of PSR-1:

A file SHOULD declare new symbols (classes, functions, constants, etc.) and cause no other side effects, or it SHOULD execute logic with side effects, but SHOULD NOT do both.

As far as I understand it, that means there shouldn't be "loose" code and classes/functions in the same file, example:

echo '123';

function my_func() {
  echo '456';
}

I agree, this sounds good. Most of the WP code complies with it except few "template" files in wp-admin. However this has nothing to do with having to split classes into separate files. Agree it "looks a bit cleaner" right now, just worried about reduced performance if we continue to add more "super short" files.