Any thing that has IF(…) : function() { } ENDIF; should never be prototyped. The issue is that many people take code from intelligent people as gold and so we get people doing function() { function() { } }. Functions contained inside other functions are worse than functions in conditionals (if the function is called twice, then you crash PHP).

Best practices should always be used when writing examples.

That said, I do think WordPress would be better served with several loading mechanisms, so that the person who wants to autoload WordPress may do so. I think it should very much be up to the developer to choose how WordPress is included. I would rather have the option to have the entire WordPress Includes in one file and the entire WordPress Administration in another file.

I suggested before that WordPress could have a build script that creates those files. I understand that having the entire WordPress library in one file would be incredibly difficult to manage. The speed advantage for those using XCache and APC, those like me, would benefit greatly from this.

This is something that can be done for 2.8 or during 2.9. I have actually done this with notable millisecond differences (I didn’t have XCache or APC in those instances). However, to be honest, it was using the time() – time(), so you may take the diffs with a grain of salt, because they aren’t worth much.

In fact, I wasn’t testing the compile time, I was testing how long require took, so the time decrease was based on removing the file IO by combining PHP.

This is partly why __autoload() also decreases performance. Not only do you add the extra File IO, but also a function call on top of it.

I guess I wasn’t clear. My problem with this idea, is foremost performance. The second is WordPress would not benefit from the current file structure with the placement of classes. Most classes are required any way, so you don’t gain much by autoloading them, because you’ll be loading 99% of them regardless. No advantage.

The third reason is that I don’t think you should just have one way to load the files. For development you want to spread the libraries out into their files, so that you can find the functions and classes quicker than browsing a 100000+ line file. This is to say, that if you were to implement an __autoload(), then you will want to provide the multiple file approach. Finally, if at all possible (using a build script) having a single file with all of the library code for those XCache and APC would be great.

Therefore, it is easy to say, “Be all things to all people,” but that is, in general life and development, difficult to impossible. In this case, besides the single file approach, these two are not difficult to implement side by side.

I also have problems with themes and other web applications that each file starts with: IF( attempted direct access to this file) die(); on every file. The problem, is that it is irrelevant, since for some of the files, there is no code that is actually executed. In other cases, you can get away with just, If( ! defined(‘ABSPATH’) ) die(); which is a lot quicker than the other approach of checking the URL, which in some cases can be spoofed (also depends on how the check works).

I guess my problem was that I was worried some guy would come along, noticed that the code was “The R0ck3rz” and decide to apply it to their project or code. No one should go along thinking that putting procedures and classes in conditionals is a Good Idea(SM). The bar needs to be set as, if this is something you should do, then you should know what you are doing.

You know what you are doing, but some novice with two months of PHP is not going to know what the problem is.

Also, I’ll rather WordPress was refactored to remove as much as possible these types of constructs in the WordPress source code. I guess, the pluggable functions would have to be as it is. Plugins hinder this as well.

I never said there would be performance gains. I never said it would be better. I’m sorry that the phrase “cut down on the number of bytes of code we load” comes across as “improve the performance” or that it sounds like I mean to use it as a performance metric.

That’s not what I meant nor is it what I propose to do.

I would never want something game-changing like that to go into core without real benchmarks. (I do not mean time() – time() on some dude’s laptop either.)

Anyway, that’s neither here nor there. The post really was just an idea – not one I intended to implement or even propose – just one I wanted to jot down.

I was thinking about how you might approach the issue of autoloading classes in apps supporting third party plugins that can put files in a number of different paths. (Suppose, for the sake of argument, that that issue is one you even want to approach in the first place.) The “dynamic” (can’t think of a more descriptive word) autoloader was one idea I had, but I wasn’t thinking specifically about WordPress when I was was considering the autoloader. I could have called this a “Path agnostic __autoload() idea” instead of a “WordPress __autoload() idea”, but decided to ground it in some context.

You’re right to be concerned if you felt this might work its way into WordPress with no real data to back it up (or in spite of data that knocks it down). Please consider this comment my attempt to assuage that concern.

How many times must I say this! Every time PHP has to go back to the compile step when in run-time, it slows down performance more so than just having everything compiled at once.

In your code PHP goes like this compile->run-time->compile-run-time. This will be inherently slower than something, like say, compile->run-time->end. You see the difference? Your code is the first, quicker code will be the second.

Now what everyone can gather from the comments, your mileage will vary. Given that my servers uses XCache and APC, your code will cripple the performance. You are purposely hindering opcode caching performance by forcing them to go back and perform the caching step again. Also, in some cases, depending on the version and opcode caching extension, the code might never be fully compiled, because the opcode caching extension does not know if it should keep the compiled code on the next run.

This is why, it is generally recommended by Rasmus (the guy who initially wrote PHP and smarter than you and me, you should read his stuff and interviews). Also, all suggestions on compile and run-time performance are geared towards those who are using XCache or APC or some other opcode caching extension.

This said, it will be faster in the cases of shared to only compile the code that is needed. That said, you gain nothing when everything is needed. Also, it will be faster to have a build script that places all of the code in a single file, instead of the 15 to 20 files that we have currently.

I think the problem comes is that compile-time is not reliability retrieved, so it is not really scientific as statistics go to diff $_SERVER['REQUEST_TIME'] to time(). You can do that to tell, but the real picture isn’t that easy to get because you really need to get in to the guts of PHP to find where time is being wasted.

If I sounds like I’m flaming you, then it is because I am. You are welcome. I got in to this with Ryan, you should talk to him sometime.

However, it increase the PHP requirement as it would now be PHP5. I hope this move will be considered, again.