The first thing you notice when visiting the PHPKG website is the claim that it “brought back all PHP functionalities.” But what does that mean?
To answer this question, we need to go back in history, to a time before PHP supported classes. Back then, life was easy and simple. You could create a file and organize your code into functions, then separate these functions into different files and use them wherever you needed. You had to use `require` or `include` statements to let PHP import (autoload) files when executing the script. It was a hassle if you needed to rename or relocate files, as you had to go through your codebase, find all the places where you autoloaded the file, and change the path.
Then PHP supported classes and introduced the `spl_autoload_register`. Using this function, you could have dynamic file loading that PHP executes when it needs a class but doesn’t have the class definition in memory. Before failing, it executes all defined `spl_autoload_register` functions to see if there is a definition for the required class. Then Composer came out. Using classes and `spl_autoload_register`, it enabled developers to use packages and build even larger applications. While Composer makes using classes a breeze, using functions is still a big problem. If you want to use function files with Composer, you need to manually add them to the `composer.json` file under the autoload files section. This eliminates the need to modify source code files when there is a rename or relocation, but it introduces another problem: memory overhead. Composer autoloads all defined files in the autoload section automatically at the beginning of the script, making them available everywhere in your codebase. There are a few use cases like helper functions or polyfill functions, but these are kept to a minimum because of the memory overhead. Defining classes is much easier than using functions in Composer.
This led to the “EVERYTHING IS OBJECT” era. Developers created classes for everything, which led to another problem: maintaining applications became a huge pain. To make code maintainable, developers keep arguing about design patterns, dependency injection, service containers, DTO classes, service/repository architecture, module definitions, manager classes, action classes, and more. Using any of these makes sense in some areas but not in others. Whenever one approach works and makes part of the codebase more maintainable, we think, “let’s apply this elsewhere,” but it often doesn’t work. Some approaches work well but raise a lot of questions.
For example, manager classes or the more modern action classes seem to work well but violate the basic definition of classes and OOP. You have a manager class with many methods or an action class with one method, but there is no “state” in these classes. The methods do not modify any state but just centralize the business logic. Why not have a function instead of these classes?
More functions are appearing in various packages nowadays. They use Composer’s autoload feature, allowing you to use them without instantiating any class, but your application pays the price in memory overhead.
Here’s where PHPKG diverges from Composer. Both use package management and support classes, but PHPKG shines when it comes to function files. It adds autoload for used function files where they have been used, meaning no memory overhead and no need for manual modification when files are renamed or relocated.
For example, assume we have a User class that uses a function named `loginByGoogle` in the Login namespace:
// User.php
namespace Application;
use function Application\Login\loginByGoogle;
class User
{
public function login()
{
// ...
loginByGoogle($token);
// ...
}
}// Login.php
namespace Application\Login;
function loginByEmail($email, $password)
{
// ...
}
function loginByGoogle($token)
{
// ...
}With this code, PHPKG adds the `require` statement for autoloading the `Login.php` file in the `User.php` class. Therefore, PHP loads this file and its functions when the `User` class is used. Using functions instead of classes can be beneficial in various situations. In fact, when you analyze a class and it has no state or properties, there’s a good chance you can replace the class with a function.
Summary:
When we say “PHPKG brought back all PHP functionalities,” it means you can use function files like we used to, without seeing everything as an object. There is no simple solution for dealing with complexity in software, but adding one more tool to the toolbox can help make our lives as developers easier. PHPKG has additional benefits out of the box, and even more exciting features will be available in the future, but the main motivation behind it was to enable the direct use of functions.
