Why does Jet use .php files as a data store and configuration source?

Wondering why you found db.php in ~/application/config and not db.ini or db.xml? Or why there is a list of installed modules installed_modules_list.php in the ~/application/data directory and not something else? There are technical and, above all, measurable and comparable reasons for this.

It would be best to show the possibilities and different alternatives, for example, to bend the configuration and demonstrate the advantages and disadvantages of the solution on them.

Alternatives: .ini files

Advantages:

PHP includes the parse_ini_file and parse_ini_string functions - so there is no need to implement anything extra in order to read the data.

Disadvantages:

While the .ini file options are really decent, they are still limited and not that flexible.
PHP has implemented parsing, but not the creation of .ini files. That would need to be implemented. But that's not such a major problem.
With some oversight and direct access to the configuration directory via URL, .ini files are easily directly readable ...

Alternative: XML

Advantages:

It is possible to store virtually any data in a meaningful way.
XML is a widely supported standard with good support in PHP.

Disadvantages:

As we will show below, there is quite a significant technical overhead for processing XML.
With some oversight and direct access to the configuration directory via URL, XML files are easily directly readable ...

Alternative: JSON

Advantages:

Back then, it is possible to store virtually any data in a meaningful way.
And JSON is now a widely supported standard with good support in PHP.

Disadvantages:

Here we will further demonstrate the overhead for processing ...
With some carelessness and direct access to the configuration directory via URL, JSON files are easily directly readable ...

Alternative: serialized data using PHP functions

Advantages:

It is possible to store virtually any data.
Relatively fast processing.
Everything needed is in PHP.

Disadvantages:

It is not an ideal format for humans and it is advisable to make configuration and other data readable and also manually editable by developers.
With some carelessness and direct access to the configuration directory via URL, the files are easily directly readable ...

Alternative: some special data format (more or less standard)

Advantages:

... no objective advantages

Disadvantages:

The necessity to implement and maintain useless code (untenable cost - untenable investment of time and money).
Almost certainly annoying technical overhead.
With some oversight and direct access to the configuration directory via URL, the files are easily directly readable ...

Current solution: .php files containing field declaration

Advantages:

As we'll show in the comparison, objectively the fastest solution technically (for several reasons).
Easy to store and read arbitrary data.
Easily readable and modifiable files in a format the developer is very familiar with - it's his own.
If, due to a bug in the configuration, the ~/application/config directory could be accessed via URL, nothing would be displayed this way anyway. It's infinitely safer.
PHP works with files like any other script. That is, it can (but doesn't have to) use, say, OPCache on them, and there's the possibility of having the configuration nicely parsed in memory. This can literally cut out a lot of overhead when processing a request.

Disadvantages:

.... some may find it a little "punk" and cool at first :-)
You have to account for the possible OPCache effect (and flush this cache if needed).

Comparison

Based on the arguments, it can be assumed that PHP files will be the fastest and therefore technically the best solution. However, the theory needs to be verified. And we will show the result of such verification.

First what we will compare. From all the alternatives, I have selected two candidates - competing technologies that can be considered namely: JSON and XML. The reason? .ini files are relatively inflexible (or not as flexible as I would like), serialized data is not suitable for possible human intervention, and I don't consider a special data format at all - no reason to do so when functional and fully sufficient alternatives are available.

Method of comparison

It is necessary to compare comparables and limit side effects. Thus, I created three separate PHP scripts completely without any framework, purely short raw single-purpose scripts.

Each script was supposed to do the same thing, which was to retrieve completely identical data. Or rather identical in that they always contained the same information, but in a different data format each time.

I placed the scripts on my local webserver. I didn't use any shared hosting like that. I did this so that I was in full control of the environment and knew