Hi, > Doesn't that just take us back to the "generic types are only optionally > checked" scenario you were trying to avoid?
Of course, my idea would also require bundling and enabling opcache by default with PHP and actually requiring the preloading+compilation step in order to run any code, like for any other statically typed compiled language. I.e. no more REPL-like, open world assumptions: all referenced classes and types must be present (or autoloadable) at compile time, with no way provided to disable compile-time type checks, like for any statically typed language (of course this would be somewhat of a breaking change, PHP 9-worthy). > you've got to switch from rules for loading classes at runtime to generating > a static preload list in advance. > To be reliable for static analysis, that preload list would need to be > *comprehensive*, defining every symbol up front, then making a second pass of > cross-file analysis. The preload list does not have to be generated manually, PHP itself could autonomously autoload all required classes at compile time (this differs from the current behavior, where autoloading is only triggered during execution of code mentioning not-yet-loaded classes). >That makes it look very much like a separate build step, rather than something >integrated into the normal execution pipeline. Well yeah, but it doesn't have to be separate from the execution step, I.e. I don't see why running a script using php a.php should not be able to autoload all reachable classes during compile time instead of at runtime, I.e. because they're mentioned in typehints, not because the function using the typehint is being executed. >I've said before that this might be the way PHP should go - a native "module" >concept, with full pre-compilation - but it would be quite a radical change. This is a different, unrelated matter, and it would actually be super cool to generate a single executable using function JIT, bundling both the compiled php code and php itself; I've actually already done this as an experiment with another JIT language based on dynasm, it's quite simple really. > Perhaps an alternative is to change the rules of when autoloading can be > invoked, by allowing the preload script to recursively autoload every symbol > it can identify, rather than waiting for the relevant code to be executed. I > think this is how current offline static analysers work. Precisely. > That doesn't solve the "optional checks" problem, though, if preloading > remains optional. We could produce an error if any generic/extended type was > encountered without being preloaded, but that poses a dilemma for libraries: > either don't use the new types, or impose a requirement for applications to > use preloading. I'm not convinced there's an easy compromise here. No need to preload, just autoload at compile time like you said, and polyfill missing classes that cannot be autoloaded. Regards, Daniil Gentili.
