2.7.0. Xpdo:: GetService (). Deciding how to use the namespace PHP for classes while respecting the PSR-4 standard

[ALexeyP0708]

I understand, it is foolish to offer without detailed tests.
I will explain my situation first.
I am developing in OS "Windows".
It is known that in 'Windows', when writing paths, slash (/) and backslash (\) have the same meaning.
When writing my classes, I used a namespace.

<? php
namespace MyFirm \ Model \ Product;
class GoodClass
{
}

created object service

$ path = $modx-> getOption ('core_components', null, $modx-> getOption ('core_path'). 'components /');
#obj=$modx-> getService ('modGoodClass', 'MyFirm \\ Model \\ Product \\ GoodClass', $path);

And it works well in Windows.

Then I wondered if it was working by chance, and in Linux everything would break.

because Linux does not accept a backslash (\) as a path delimiter.
Checked MODX on Linux hosting.
There really is a problem.
Looking at the xPDO code, a solution was found.
modx 2.7.0
File: www \ core \ xpdo \ xpdo.class.php
Class: xPDO
Method: _loadClass
replace line: 653

$fqcn = str_replace ('.', '/', $fqn). '.class.php';

to

$fqcn = str_replace (['.','\\'], '/', $fqn). '.class.php';

And
replace line 662:

$mapfile = strtr ($fqn, '.', '/'). '.map.inc.php';  

to

$mapfile = str_replace (['.', '\\'], '/', $fqn). '.map.inc.php';

Changes checked on linux hosting. Everything is working.

These changes will not affect the code as a whole.
They will only conduct a more valid path validation.
And it will be possible to use the class namespace under the PSR-4 standard.

I agree that it is necessary to take a set of measures to implement the full functionality of the PHP namespace.
But this is sometimes enough to enable app development for MODX 2.7 using the PHP namespace.

[ALexeyP0708]

Please make such changes. Then I will have the opportunity to publish my work applications, and bring fresh solutions to MODX, which may appeal to a large circle of people and support your project.

[ALexeyP0708]

Actual for xPDO 3