BackwardCompatibility::exportStatic() causes performance drop about smf HOT 3 CLOSED

Could we compute it and store the result of this in a file somewhere? During mod install, we can recompute this data.

from smf.

I've been thinking about that since @albertlast suggested the same thing on the discussion boards. At this point, though, I'm thinking no. The BackwardCompatibilty::exportStatic() method is only intended to provide aliases for deprecated functions and variables that were part of vanilla SMF. Installing or uninstalling mods will never change that list of global functions and variables. That list is, in fact, completely invariant. So we can just hard code the exported function and property names and call it a day.

I might even centralize the list into the BackwardCompatibilty trait itself, rather than having it scattered among all the various classes definitions. Having it distributed that way was helpful while I was in the midst of the OOP rewrite, but now that that's done, there's probably no need to keep it that way.

Moreover, there are some things that would be easier if we have a centralized list. In particular, there is a bit of a bootstrapping problem with the distributed list. Right now, if a mod wants to call a deprecated function that is defined (via BackwardCompatibilty) in a class that has not been loaded yet, we have to do some silly stuff in order to load the class on the fly. (All those vestigial backward compatibility files littering the codebase are part of that silliness, for example.) If we have a single, centralized list of properties and methods, we can declare them all at once without worrying about the bootstrapping problem or any other silliness.

from smf.

For those who might be interested, I explored the idea of having a centralized list, as outlined in my previous comment. It turned out to be more trouble than it was worth.

from smf.