My biggest concern about doing something blindly like this is that it implicitly creates multiple class name definitions or class file paths without explicitly supporting these features in the system. Another thing that worries me is the performance impact of scanning the filesystem for a class name in one of several ways (if I'm counting right, the libraries/cms path would have at least three class name variants accepted by the autoloader, depending on the order of the loaders this would mean if you namespaced the code in place (personally I'm not a fan of mixing namespaced and non-namespaced code with autoloader rules in the same path), what's the performance hit of including Joomla\Cms\Version\Version versus the current JVersion class name?).

Another thing that makes me uncomfortable is you're supporting PSR-0 and PSR-4 with two different conventions meaning it is entirely possible now for extensions to have three class name conventions and that's just if they're working with the legacy MVC tree (ContentControllerArticle, Components\Content\Controllers\Article, and Joomla\Component\Content\Site\Controllers\Article). Only one of those is supported by the MVC factory classes right now so the rest are just overkill without explicit support. And do we really need to support both PSR-0 and PSR-4? Even PHP-FIG considers PSR-0 deprecated, I'd say focus only on PSR-4 and actually deprecate our PSR-0 support.

Something that deviates from both autoloading standards is the conversion of directories in the autoloader's code. You're converting singular names to plural just to support the existing filesystem structure. To me this is a bad sign; it creates some annoying restrictions on how the autoloader is used system wide. IMO the correct approach is to not convert that; the autoloader should treat Joomla\Component\Content\Site\Controllers\Article and Joomla\Component\Content\Site\Controller\Article as two different files and two different classes.

The other deviation is with the view.*.php files. Since these aren't structured in a PSR- compatible way, our PSR- autoloaders shouldn't try to load them. I'd rather see autoloading support follow the published standard versus having some "gotcha's" in the code and have extension developers opting to use the new convention refactor their code appropriately; it creates a cleaner solution in the long run. With that said, if you're going to stick with this deviation it also needs to be supported for controller files as the MVC layer supports this for those too.

I fully support the notion of finding a way to autoload the CMS. But my gut feeling is that this first go which implicitly supports several class name definitions and every autoloading definition that ships with Joomla shouldn't be the way to do it. It needs to be more targeted and a more explicit change that follows the established standards, not a Joomla fork of the standards to try and force the existing conventions to just work with them.

@mbabker

without explicitly supporting these features in the system

Could you be more specific about? Cause I don't really understand what you mean by that.

Another thing that worries me is the performance impact

If class already loaded like with JVersion, it would not go to PSRs

personally I'm not a fan of mixing namespaced and non-namespaced code with autoloader rules in the same path

Well, may be you're right, may be you're not. I've implemented and tested what've been writen here as I mentioned: https://volunteer.joomla.org/reports/115-joomla-4-architecture-sprint-odense-dk

you're supporting PSR-0 and PSR-4

PSR-4 for Joomla can have doubts right now of how it should be treated as I see from your comment.
With PSR-0 it's not, it's straight as it gets. + PSR-0 used and, I believe, will be used with registerNamespace(), so does it need to be removed - not my decision.
registerNamespace() suites better when using PSR-0 and mixing it in PSR-4 IMHO is not a great idea. (Also it's like mixing PSR-0 and PSR-4 in same function)
By the way in my opinion

Joomla\CMS = > /libraries/cms
Joomla = > /libraries/joomla

is suites PSR-0, but not PSR-4. Any way they described like PSR-4 at joomla-4-architecture-sprint-odense-dk

Even PHP-FIG considers PSR-0 deprecated, I'd say focus only on PSR-4 and actually deprecate our PSR-0 support

PSR-0 is used and, I believe, will be used with registerNamespace(), so does it need to be removed - not my decision.
But maintainers can at any time delete few lines of code, when they'll make decision to remove PSR-0.

IMO the correct approach is to not convert that; the autoloader should treat Joomla\Component\Content\Site\Controllers\Article and Joomla\Component\Content\Site\Controller\Article as two different files and two different classes.
IMO the correct approach is to not convert that; the autoloader should treat Joomla\Component\Content\Site\Controllers\Article and Joomla\Component\Content\Site\Controller\Article as two different files and two different classes.

"Controller\Article" suites better when you appeal it it but current joomla folders naming covers "Controllers\Article". I'd suggest to change folder naming in future.

But my gut feeling is that this first go which implicitly supports several class name definitions and every autoloading definition that ships with Joomla shouldn't be the way to do it.

Support of classes and namings that are existing now is added as you said like "gotcha's" because of implementation of proposal from @wilsonge

Ideally but not quite as necessary as 1) if you could modify the MVC class finders to support the namespaced structure above it would be good

And those "gotcha's" can be divided and deleted in 40 seconds when maintainers will think that time is came.

Could you be more specific about? Cause I don't really understand what you mean by that.

JControllerLegacy, JModelLegacy, and JTable have factory getInstance methods that expect specific name structures. You can somewhat manipulate those passing the name and prefix arguments to work with namespaced stuff (I did it with the patch tester component before dropping the JTable class support), but their defaults are the current non-namespaced class names we have. So these methods need to also support looking up classes following the namespace conventions otherwise there is no benefit to namespacing extension code unless you do something like I did with the patch tester where you use the "no MVC" interfaces and just build everything yourself.

Well, may be you're right, may be you're not. I've implemented and tested what've been writen here as I mentioned: https://volunteer.joomla.org/reports/115-joomla-4-architecture-sprint-odense-dk

What was decided there was the conventions for how namespaces should be set up. To me that's not an issue at all. I don't believe the intention was to take PSR-4 as a starting point and manipulate it so that existing file paths could be autoloaded with namespaced code versus the current manual load that is done through the factories.

"Controller\Article" suites better when you appeal it it but current joomla folders naming covers "Controllers\Article". I'd suggest to change folder naming in future.

The way the current code is written (if I've read it right) is that you cannot have singular folder names for controller, model, table, and view; the autoloader arbitrarily pluralizes those names in the filesystem. I would suggest not doing this. If someone prefers the controllers (plural) naming structure, they should be able to use it; same for singular (odds are though that the factory methods will probably dictate a namespace segment around this so it'll become a moot point in terms of deciding names).

Support of classes and namings that are existing now is added as you said like "gotcha's" because of implementation of proposal from @wilsonge

IMO it's not a good idea to make the current code structures autoloaded by manipulating the PSR-4 (or 0) standard to match Joomla's existing filesystem structure. To me the cleaner solution would be to add the namespacing support as decided previously to the autoloader so that the base prefixes for various extension types are correctly configured but once you get into those lookup paths they follow the standard at that point. Yes it requires extension developers to refactor their code; rename classes and move files in the filesystem to add support for the new feature, but in the long run I would suggest that is the better path to take. If we wanted to make the existing class/path conventions autoloaded (not such a great idea because the existing conventions at least in the MVC layer use duplicate class names), that should be done separately from adding namespacing autoload support.

1) I didn't get your point. Is it that you can't load JTable? You can.
What stops you from using MVC?

2) So?

3) So what the problem of doing this?
Controller\Article is checked first
and only if it is not found Controllers\Article is checked.
If Controllers\Article is supplied - only this name is checked

4) IMO YOO is "cut the rope"
I'm not trying to force old code to stay here forever. I'm trying to give people a test of functionality for smooth conversion of old style to new. So people can be prepared.

And what approach are you trying to take? Just change OS of people who worked with Windows for 10 years to Ubuntu on Sunday, and tell them this news on Monday? You'll get applause.

I've said before: I don't suggest this legacy hooks to last forever, but until public announcement "We don't use it any more, it's doomed."

1) You'll have a harder time using the existing MVC layer, or for that matter most of Joomla's factory methods, with namespaced code because most of them don't support namespaces (the ones that are probably the easiest to work with are ironically the controller, model, and table getInstance methods). So there is absolutely zero benefit to accepting a pull request only for autoloading when it breaks code if you try to use it. For example, JControllerLegacy::getInstance() only allows you to give a controller name prefix. This could probably be the part of the fully qualified class name up until the final class segment (so Joomla\Component\Content\, and yes the trailing slash is required). The internal code concats your prefix, the word "Controller", and the (optional) subclass being loaded. So your class names would be Joomla\Component\Content\Controller or Joomla\Component\Content\ControllerArticle. OK, that's not so bad in the long run. This is actually one of the better factories. Compare it to something like JCategories::getInstance() which assembles the class name in full internally and doesn't have a way to cope with alternative structures; so ContentCategories couldn't be namespaced at all without breaking things.

2) "So?" What are you trying to imply here?

3) The problem is that the existing standards do NOT allow for this type of behavior. Both PSR-0 and PSR-4 essentially map to the filesystem after a namespace prefix is specified, so the system should only be looking for Controller\Article at the Controller\Article file path. It shouldn't try a fallback path of Controllers\Article. We aren't trying to autoload the existing class/file conventions; IMO that's going to cause more issues than not because of the use of duplicate class names and the fact that you have to rename your classes anyway to take advantage of namespacing. So why should we introduce "legacy hooks" into new behaviors that you have to fully opt in to to begin with?

4) OK, the only benefit to this is to make it dead easy to test the changes. But I still don't believe it's the right behavior to try and autoload the existing filesystem convention. It would be better to simply follow the established standards in PSR-0 and PSR-4 at this point; it's less deviation that has to be accounted for, less code to maintain, and is not as susceptible to bugs being introduced.

And what approach are you trying to take? Just change OS of people who worked with Windows for 10 years to Ubuntu on Sunday, and tell them this news on Monday? You'll get applause.

Not trying to make that kind of change at all. If you're namespacing code in Joomla, you're going to have to put in a fair bit of work, especially because there are parts of Joomla that just do not account for the possibility of namespaced code. So I don't see the benefit beyond ease of testing to introduce rules into the autoloader that allows code following a new convention to use an old convention's structure.

Actually, AFAIK, I may be wrong as I'm not Joomla member, so how could I know the truth,but any way... Actually, AFAIK, Joomla has no such thing like ContentCategories, it has Categories spliced by extensions.
So...

JCategories::getInstance('com_content');
Joomla\Legacy\Categories::getInstance('com_content');

Will give exactly same result.

So? What are you view on how things should be implemented? New loader need to be added and people should refactor all the code at one day instead of adding new loader and giving people some time to move on to it before removing other approaches?

Did you even tested and looked into code to try to figure out whats happening?
If you have classes in supplied path (Controller\Article), it would not try legacy hooks and fallbacks and will not go to Controllers\Article, so both classes can be named as Class Article and you will have no issues. Issues will be only there were issues would be any way with any loader.
The main "thing" in using PSR-4 for with legacy for some time is to give people ability to write own extension with PSR-4 loading of all classes even if they working with not changed to PSR-4 com_content, so the will have same code throughout and will not be forced to mix approaches.

It's not only that. It's allowing to everyone to make changes in moving Joomla on to PSR-4 bit by bit, so you can split a big part of work into 10-30 smaller parts.
Not

to introduce rules into the autoloader that allows code following a new convention to use an old convention's structure

but

to introduce rules into the autoloader that allows code following a new convention to use with old structure before convention will become the only one, so people can prepare.

It's pretty big conversation and I starting to be annoyed by it , because any of you 'thoughts' I need to
parry instead of you looking deeper into things (also test the code) and only then think and be afraid.
May be I'm wrong, but also from this conversation I get the feeling that you don't want to even understand my point fully, and just keep to be afraid of shadows without looking back to find out who`s shadow it is.

Actually, AFAIK, Joomla has no such thing like ContentCategories, it has Categories spliced by extensions.

I linked right to the ContentCategories class in my last post (again here). All of the core content component types (banners, contact, content, newsfeeds) have similar classes.

So...

JCategories::getInstance('com_content');
Joomla\Legacy\Categories::getInstance('com_content');

Will give exactly same result.

When calling JCategories::getInstance(), nothing changes if you don't change anything in your extensions. But, the getInstance method does not support looking up subclass names by namespace; look at how it assembles class names to create instances. The other big one that affects all extensions is in JRouterSite::getComponentRouter().

The MVC classes and JTable specifically could theoretically already support namespaces (I know JTable does already, and since JModelLegacy::getInstance() has a similar signature it should too; JControllerLegacy::getInstance() can support it but it's a bit "odd" (see above example), and from the looks of it JControllerLegacy::getView() may have issues), that part isn't as bad as I originally thought it might be.

So? What are you view on how things should be implemented? New loader need to be added and people should refactor all the code at one day instead of adding new loader and giving people some time to move on to it before removing other approaches?

The support for the new loader is added without causing existing classes/files to be unexpectedly autoloaded (in part because the existing file structure supports duplicate class names and that's not feasible with an autoloader). So the accommodations for autoloading view.*.php files or things like pluralizing namespace segments shouldn't be there; the former if not dealt with properly could cause duplicate classes to be loaded and the latter is more of a personal preference than a code issue. Actually, looking at your code again, it seems like the duplicate class issue wouldn't exist as it'll force HTML format if one isn't found in the segment it's checking. Still to me it doesn't feel like a good idea to autoload existing files. If you're already refactoring your code to implement namespacing, why can't you also rearrange your file structure to work with the new standard at the same time?

I'm not trying to shoot down your work, nor am I "afraid of shadows without looking back to find out who`s shadow it is". I'm addressing what I perceive as possible issues based on having read the code in this pull request and having used Joomla (contrary to what some people will say about me only using Joomla behind an IDE I do actually build, deploy, and maintain websites with it) and understanding some of the quirks that makes autoloading some of the existing extension files a less favorable option. So getting back to the root of it, my main issues are:

• Supports up to three class name conventions for almost every class (PSR-0, PSR-4, and the existing conventions or autoload rules depending on what portion of the application we're talking about); IMO that's one too many, I would prefer we focus only on PSR-4 for the namespacing piece of it. I'd still suggest deprecating our PSR-0 support as even PHP-FIG considers it deprecated, but not doing that I'd suggest also just not adding new features to our PSR-0 loader.
• Attempting to autoload existing file paths which aren't PSR compliant; if you're refactoring your code to use namespaces anyway, I don't see the issue in also renaming files.
• Factory methods in the application not supporting namespaced class lookups which makes implementing namespacing less favorable or not possible in some cases. Before this can be the suggested way forward, the application is really going to need to support these types of lookups. OK, this can be addressed in follow on pull requests, but it really needs to be said/known now so there are no surprises regarding the work that's coming up from adding this support.

My bad.
ContentCategories class will only have issue because of it lays in file category.php instead of categories.php... This is ain't right, but autoloader can have one more hook to catch this kind of situations.

About Router... Really don't get your point on it. As also I can't understand how you triggered the function that you've highlighted, but with some tweeks (not tweeks of the processes involved in this issue, but code to trigger this function):

$app = new Joomla\CMS\Application\Cms();
$lang = new Joomla\Language();
$app->loadLanguage($lang);
$uri = Joomla\Uri::getInstance('http://site.dev/index.php/component/users/?view=registration');
$router = new Joomla\CMS\Router\Site(array(),$app);
$router->parseSefRoute($uri);

And it does what it suppose to.

Well any way, next part:
You've said by yourself that it wouldn't cause the issues because of how loader is done, so I guess I can skip this few sentences...

if you're already refactoring your code to implement namespacing, why can't you also rearrange your file structure to work with the new standard at the same time?

This isn't about me. It's about Joomla and developers.
But if you'd be better if I'll say me, then okay... I could rearrange code and file structure of my component, but I can't say if core or 3rd party extensions of my users are already rearranged, so I would call JCategories::getInstance(), right?
Is it okay for your eye?

$uri = Joomla\Uri::getInstance('http://site.dev/index.php/component/users/?view=registration');
$categories = JCategories::getInstance('com_content');
$logger = new Core\Plugin\System\Log();

or next one will be less mixed?

$uri = Joomla\Uri::getInstance('http://site.dev/index.php/component/users/?view=registration');
$categories = Joomla\Legacy\Categories::getInstance('com_content');
$logger = new Core\Plugin\System\Log();

May be not the best example, but I believe it's enough to get my point.

makes autoloading some of the existing extension files a less favorable option

To leave it as IS for ever - yes (it is less favorable option).
To make it temporary available for more smooth sailing and code migration - no (it is not less favorable option).

To sum up:

• Yes, in nearest future - Joomla need to move everything except 1 approach away. And I believe that this one is PSR-4. I love legacy Joomla approach - everybody use to it, but need to move forward. But move smoothly and not bumping everyone who in the tail of the road.
• It's not for preserving my, or somebodies else code and file structure, it's to allow to use the edge approach and single code style throughout in the same time, without bothering about other extensions are not so fast in transferring.
• OK, I don't what to be overhead but so far: give me those locked cases and I'll give you lock pick. You never know what you can do till you try.

Unless you've class aliased stuff and I missed it, I don't see how you could call JCategories::getInstance('com_content'); (or whatever it's called as a namespaced class) and get an instance of Joomla\Component\Content\Helpers\Category (that'd be the expected class name given the path that the factory is trying to load manually if the class doesn't already exist) if you have namespaced all of your extension code because that specific factory class is building a specific class name format. If ContentCategories is aliased to Joomla\Component\Content\Helpers\Category then it would work fine. That's where I'm saying things will most likely have issues; the files will get loaded OK but the expected classes won't be found in the files and that's an issue. You could get around it with a stub in the file:

class ContentCategories extends \Joomla\Component\Content\Helper\Category {}

namespace Joomla\Component\Content\Helper;

class Category extends Joomla\Legacy\Categories {}

Which still requires you to maintain both class conventions until the internal code is "smart" enough to load the namespaced stuff correctly.

Well if I wouldn't pay attention to it then there would be no legacy support + at least half, but I believe all of my tests would fail as Joomla core is not namespaced.
https://github.com/alex7r/joomla-cms/blob/85404f0de41f8d1724886090760c955e427421f8/libraries/loader.php#L769-L818
There is

    if (!class_exists($class, false))
    {
        if (class_exists($className, false))
        {
            class_alias($className, $class);
        }
        if (!$classPathParts && ucfirst($className)=='controller')
        {
            // Hook to support current (9 july 2016) class naming
            $className = $classPrefix . $className;
        }
        // Special treatment for helpers that are in helper folder
        if (stripos($ipath, 'helper') !== false && stripos($classPrefix, $className) !== false)
        {
            $className = $classPrefix;
        }
        else
        {
            $className = $classPrefix . $className;
        }
        if (class_exists($className, false))
        {
            class_alias($className, $class);
        }
        else
        {
            // Try to build full naming with/without J prefix
            $fullLegacyClassName = str_replace(DIRECTORY_SEPARATOR, '', $ipath) . $className;
            if (class_exists($fullLegacyClassName, false))
            {
                class_alias($fullLegacyClassName, $class);
            }
            elseif (class_exists('J' . $fullLegacyClassName, false))
            {
                class_alias('J' . $fullLegacyClassName, $class);
            }
            // If class not exists (and strpos contains Joomla - try to add J prefix)
            // But let's just check J prefix as file loaded any way
            elseif (class_exists('J' . $className, false))
            {
                class_alias('J' . $className, $class);
            }
        }
    }

It's implementing class aliasing - making legacy support possible.

Since you a. reference the information from Joomla! 4 architecture sprint from July 2015 b. I was there and c. I proposed the namespacing item to begin with: I have to set the record straight.

The proposal I had made and which was accepted was to get 100% rid of all non-namespaced code in Joomla!. Everything would be namespaced and loaded with Composer's PSR-4 autoloader.

The scope of the document you mentioned was to provide a guideline to how namespaces would be set up, NOT how to write an autoloader that bastardizes two FIG standards, adding layers and layers of Joomla cruft on top. In fact, the document did hint you how to add prefix to folder mappings into Composer's PSR-4 autoloader. For example, component com_content:

• Joomla\Component\Content\Site maps to components/com_content
• Joomla\Component\Content\Admin maps to administrator/components/com_content

As you can read further down I wrote "This scheme covers the need of the Joomla project(s). 3rd party developers use their own vendor namespace, so collisions are effectively avoided." In other words, each component sets up its on prefix to path mapping into Joomla!'s copy of the Composer autoloader on the condition that the prefix starts with a vendor-specific namespace.

This was definitely not a new idea. It's something I had already implemented and tried on real sites in FOF 3. That's what sold other people to the idea. It was not purely theoretical, it well-designed, following globally accepted standards (PSR-4) and well-behaved in the real world.

The document specifically didn't mention anything about MVC because that was still under discussion (some people wanted to go full CQRS, I argued that's way beyond most developers' head – but that's besides the point). In the following weeks we were operating under the assumption that controllers would go under the Controller directory, models under the Model directory and so on and so forth (hint: like I do in FOF 3). It is PSR-4 and makes sense: Joomla\Component\Content\Site\Helper\Category, Joomla\Component\Content\Site\Model\Categories (which is different to Joomla\Component\Content\Site\Model\Category, mind you!) and so on and so forth.

Trying to fall back to singular or plural names of folders or, worse, classes inside an autoloader is a massive red flag. It means that you don't understand the reason of PSR-4's existence and you don't understand what an autoloader is supposed to do. The autoloader is NOT a service locator. Do not make it behave like one. Trust me. Been there, done that, learned my lesson.

Regarding class aliasing, it's NOT the job of the Autoloader to do that. That classifies as spooky unpredictable action with system-wide repercussions (I can't load my extension's classes unless I override Joomla!'s autoloader – here comes the slippery slope). Class aliasing is the job of a separate file, like we currently do in Joomla!. Having criticised that file in the past I have to admit that I was wrong about this. Having this file is actually the best way to do it. Ideally, in Joomla! 4.x the class aliasing would be deprecated and made obsolete (removed) in 5.x. But in any case it is NOT the purview of the autoloader to define class aliases.

And yeah, on top of all that cruft being architecturally incorrect they also have an adverse performance impact (try without opcode caching on a server with nearly saturated I/O to get an idea of how slow it gets). And as Michael said it makes no sense to have that in the first place since it can only be used for any practical reason by extensions which opt in to use it, i.e. extensions which break b/c. So why implementing this PR in the pretext of b/c is beyond me.

The goal of any future Joomla! version should be to solve this kind of architectural atrocities sprinkled throughout the system, stemming from a decade of haphazard coding with reckless abandon. It shouldn't be adding more –in number and malignity– of said atrocities under the pretext of b/c.

Please stick with the published FIG standard that everyone uses (PSR-4) and add your class aliasing as a TEMPORARY measure to help developers migrate their code.

I give this PR a big ?

Ok, seems like I understand you, but you don't understand me.
Let's keep it simple:

As a developer why should I write namespaced code for Joomla extensions when it's not how things work in Joomla currently?

Any way even if I understand that in future there will be another style:

How can I see and test how would it work? How can I see what standard I need to support in a live example? There is no code in existing components + there is no 4.0 branch to look forward and be prepared.

Also may be I don't understanding something (well, only proves what I've wrote before in this comment), but how would Joomla understand where to search for 3pvendor\Admin\Table\Item() or simply classes of namespace 3pvendor\Admin, when I'm referring to them from 3pvendor2\Site\Helper?
Is there would be some "magic" or those namespaces would be parsed with Joomla loader?
If
1: point of comment beginning is proven
2: Joomla loader need to have parser (yes, without legacy support and class aliasing, but why I add it you can see in this comment + as I've said before: legacy support can be purged in a minute when time comes).

Once again: I may be wrong about something, but for me it's like "jumping" and "smooth transferring"... Some thing that can't be at the same time.

Also may be I don't understanding something (well, only proves what I've wrote before in this comment), but how would Joomla understand where to search for 3pvendor\Admin\Table\Item() or simply classes of namespace 3pvendor\Admin, when I'm referring to them from 3pvendor2\Site\Helper?
Is there would be some "magic" or those namespaces would be parsed with Joomla loader?

You're on the right path with adding the logic to JLoader to be aware of the prefixes. I don't think that's a behavior we can do purely with Composer's implementation of the PSR-4 autoloader. That part I think you've done well. It's everything after those prefixes that I'm not much of a fan of.

That said, the Composer ClassLoader does have methods to add additional path prefixes programmatically so a later implementation following the original plan deprecates using JLoader for the class loading and pushes that directory mapping via Composer\Autoload\ClassLoader::addPsr4() but for a first cut we at least see the code required to create the prefix mapping and register those paths into any PSR-4 compliant autoloader. Doing that requires making some fixes to how Joomla includes and decorates the Composer autoloader as right now the CMS bootstrap nor JClassLoader make it easy to get access to the Composer autoloader after the initial inclusion.

I am setting this to needs review

I think it is a bit of over-engineering of a autoloader and don't think this is something we should do in 3.x. Have set it to re-evaluate for 4.x

Hi Robert,
Could you contact me via alex7r@ya.ru
so I could ask you some questions on plans for JController and issues faced while trying to move on from JLegacy?

Thanks

@alex7r I think the right place for asking questions is https://groups.google.com/forum/?hl=en#!forum/joomla-dev-general

Bonus: the answer you get there it will help other too.

@laoneo Is this PR still valid/usable given the work that's gone into 4.0 namespace support?

We use a different ns structure in J4. But the priciples of this pr are done in #13672 and #15226. So I guess this one becomes obsolete. Would love if you can review the current code and give feedback for it.