Previous articles: - ➡️ [Section 04. Philosophy](/docs/04-philosophy) - ➡️ [Section 05. Principles of Operation](/docs/05-principles) - ➡️ [Section 06. Architecture](/docs/06-architecture) # SLOT-H: Autoloader (Dependency Graph) The system uses its own autoloader built on a class dependency graph. It is generated automatically and requires no manual maintenance. **IMPORTANT!** *The demo version works exclusively with MySQL. The autoloader has been adapted for this engine (currently being prepared, with direct usage added). The full version operates on a slightly different principle, using helpers for working with stored procedures.* --- ## How it works The autoloader scans all PHP files in the project and builds a mapping between classes and the files in which they are declared. The map captures not only the classes themselves but also their dependencies: - If a class inherits from another class, this relationship is recorded in the map - A class is loaded only when it is actually needed to process the request - Loading is recursive: parent classes are loaded first, then child classes The autoloader loads interfaces and traits at startup. Other classes are loaded on demand during request execution. This provides optimal performance. --- ## Class naming requirements All ecosystem classes must have a namespace identical to the path from the project root. **Example:** File `Modules/Base/Controllers/Cli.php` must have namespace `Modules\Base\Controllers` File `Application/Assistance/Database.php` must have namespace `Application\Assistance` This provides two advantages: 1. **Predictability** - the class name always tells you which folder it's in 2. **Uniqueness** - you can have two classes with the same name in different namespaces --- ## Autoloader generation The autoloader is not edited manually. It is regenerated by the `Application/Tools/createAutoloader.php` script. Generation is required in the following cases: - A new class has been created - A class has been renamed - A class has been moved to another folder - A class has been deleted - The inheritance hierarchy has changed (parent class added or removed) **Important:** creating a new class without regenerating the autoloader will result in a `Class not found` error. --- ## Static files In addition to classes, `createAutoloader.php` processes static files (css, js). A hash is calculated for each such file. The hash is stored in the `static_files` table. When a page loads, files are included via the `Scope` controller, which serves the file by hash. The browser caches the file, but when the file changes, the hash changes, and the browser loads the new version. This solves the static caching problem without needing to manually change versions in code. The latest version of the file is always served. Minification and obfuscation are disabled in the current version. --- ## Comparison with traditional approaches Most PHP frameworks and projects use the standard Composer autoloader based on the PSR-4 standard. It works on the principle of "namespace → file path". This is a reliable and fast solution that has become an industry standard. This system's autoloader works differently. Instead of searching for files using PSR-4 rules, it uses a pre-built mapping between classes and files. This map is generated by the `createAutoloader.php` script and contains a complete list of all project classes. ### Key differences **1. Map generation, not rule-based lookup** The standard PSR-4 autoloader calculates the file path based on the class name and namespace prefix. This happens every time a class is referenced. The system does not calculate the path - it takes it from a pre-built map. This is faster because it requires no calculations or file existence checks. **2. Inheritance hierarchy awareness** Unlike Composer, which simply loads the specified class, the system's autoloader analyzes the inheritance hierarchy. If a class inherits from another class, this relationship is recorded in the map. When loading a class, the system automatically loads all its parents in the correct order. This eliminates errors caused by parent classes not being loaded yet. **3. Single source of truth** PSR-4 rules are described in `composer.json` and can be complex to understand, especially when there are multiple namespaces with different paths in the project. In this system, the path to a class is always unambiguously determined by its name. This makes the code more predictable and easier to analyze. **4. Static file integration** Composer only handles PHP classes. The system's autoloader also processes static files (css, js) in parallel, calculating their hashes for cache management. This ties code and static file management into a single process. **5. Strict naming requirements** The PSR-4 standard allows various directory organization options. The system requires that the namespace exactly matches the path from the project root. This constraint makes the project structure uniform and eliminates situations where one developer uses one style and another uses a different one. --- ### What this gives in practice - **Predictability.** Opening any file, you can immediately tell its namespace just by looking at the file path. And conversely - knowing the class name, you can immediately tell where to find it. This speeds up work with code and reduces cognitive load. - **Reliability.** The autoloader does not search for files on disk. All paths are known in advance. This eliminates situations where the autoloader cannot find a class due to errors in the rules. - **Performance.** The absence of file search operations and path calculations makes class loading faster, especially with a large number of classes. ### The downside The autoloader must be regenerated whenever the class structure changes. This adds a step to the development process. However, this step is automated and takes seconds. In Composer, a similar step also exists - the `composer dump-autoload` command. The difference is that in this system it is mandatory, while in Composer it is only needed when autoloading rules change. --- ## What's next? - ➡️ [Section 08. Database Storage Convention](/docs/08-database) - ➡️ [Section 09. Parametrization](/docs/09-parametrization) - ➡️ [Section 10. Multi-project](/docs/10-multiproject)