Unfortunately PHP does not provide any means to autoload the files that
a functions is located in, even if they are in an namespace.
To work around this, Composer makes use of an `autoload.files` section
in the `composer.json` file. Shortly after the Composer autoloader is
registered with the `spl_autoload_register` call it also includes any
files listed in this section.
Moodle does not do this and really we should be doing so.
This change adds a section to the autoloader registration method which
loads all of the files defined in any third-party library included in
our `lib` directory which contains any `composer.json` file with such a
stanza.
Note: No backwards-compatability layer is included for manual inclusion
of filter.php as this is not a public API. Inclusion should have always
been through the filter manager, and the filter's own unit tests.
This commit:
- introduces a \tests\ sub-namespace for use in unit tests only
- the path to this the tests/classes directory of the owning parent
- files here are excluded from unit test runs
This is agreed per policy in MDL-80855.
Subsystems do not support the notion of a `db` folder. Instead we must
conflate the lib/db/legacyclasses.php syntax to allow it to support
paths as either a string, or an array with [subsystem, path].
This commit adds the PSR-20 ClockInterface to core, with a
moodle-specific extension to the Interface at `\core\clock`, and a
standard clock at `\core\system_clock`.
Further clocks are provided as `\incrementing_clock` and `\frozen_clock`
which are available to unit tests using:
- `$this->mock_clock_with_incrementing(?int $starttime = null);`
- `$this->mock_clock_with_frozen(?int $time = null);`
For the incrementing clock, every call to fetch the time will bump the
current time by one second.
For the frozen clock the time will not change, but can be modified with:
- `$clock->set_to(int $time);`; and
- `$clock->bump(int $seconds = 1);`
The PSR-4 specification does not preclude a single namespaces from
having multiple sources. This is the case for several PSR standards
including standard packagist packages distributed by PSR:
- PSR-7 - HTTP Message Interfaces: \Psr\Http\Message
- PSR-17 - HTTP Factories: \Psr\Http\Message
- PSR-15 - http-server-handler: \Psr\Http\Server
- PSR-15 - http-server-middleware: \Psr\Http\Server
This commit will implement the Guzzle library in core
to make it usable in different locations.
Co-Authored-By: Andrew Nicols <andrew@nicols.co.uk>
Co-Authored-By: Safat Shahin <safat.shahin@moodle.com>
Right now we have the information only in docs:
- https://docs.moodle.org/dev/Core_APIs
- https://moodledev.io/docs/apis
And, in fact, we are crawling those pages to get the information
from various tools (moodlecheck, CiBoT...). Obviously, that's far
from ideal, the source only has the current list of APIs, and
there isn't much information there but the names.
So we are moving the source of information to be in core, so it
can be modified between branches, and contains richer information:
- The component the API belongs to, usually a subsystem or core.
- If the API can be used as level 2 namespace.
- If the API can be used as level 2 namespace out from its component.
Note that all that information has NO USES right now in core (and maybe
never will), but tools/checkers will benefit enormously by having that
information at hand, so we can check for namespaces, categories and
other bits way better.
Also, once we have this, the APIs dev documents linked above, surely
can be improved by being automatically generated and include all the
meta-information available.
It also includes a very basic json schema validating the basis. It can
be tried online @ https://www.jsonschemavalidator.net , or any other
tool. PHP requires extra libraries to be able to perform the validation.
Covered with unit tests, both api-related functions and structure validation.
Andrew Nicols