Thanks @Bakual

This will fix the php-linting inside Joomla but not for third-party extensions.

The logical way would have been IMHO to have an auto-loading jregistry.php file with a class:

class JRegistry extends \Joomla\Registry\Registry { }

This would fix the php-lint issue in Joomla and in all extensions. Additionally with a @deprecated 4.0 use \Joomla\Registry\Registry php-doc comment it would allow for correct notices in IDEs.

Performance-wise it would have been better than the alias that is made in the auto-loader each time a new JRegistry object is needed.

Plus, it's only 2 files to change: add jregistry.php and remove the corresponding strange alias magic in auto-loader, instead of hundreds.

Thoughts ?

@beat do I understand correctly that you are proposing to add a new files with an empty class?

@betweenbrain not empty since it extends another class, but not adding anything to it.

The only issue i see with both current approach and my proposal is that everywhere where there is a check $myVar instanceof \Joomla\Registry\Registry and you have a JRegistry in $myVar, it will work, but not the other way around. However, right now with the magic alias, I'm not even sure that instanceof JRegistry works.

@beat Apologies, I meant to write an empty extend not class.

I'm not a fan of adding files just to appease IDE's and linters. But, as it could help extension developers, I could see a fair compromise with them being in the repo but not builds.

However, right now with the magic alias, I'm not even sure that instanceof JRegistry works.

It does. The alias logic hooks into PHP's class_alias function which registers the alias globally. So all references to the old class names are mapped via PHP's internals to the new references. Without being able to alias the old names to new, the original PR would have never been acceptable because of the class name changes and the only way to change to namespaced classes would have been at a major release, meaning either we never namespace our code (some would prefer it, there's pushback on any breaking API changes) or we have a major release with Drupal's level of B/C.

Extensions supporting 2.5 and up should theoretically be able to get around the lint issue you're describing with a version_compare statement (untested, don't blame me if it doesn't work )

// Run this check just after the defined or die line, before declaring your class
if (version_compare(JVERSION, '3.3', 'ge') {
    use Joomla\Registry\Registry as JRegistry;
}

If that doesn't work, extensions can also ship a dummy JRegistry class. I'm not saying there's a single right solution for everyone here and arguments can be made all ways. But, there are solutions that can both go into core and not.

Thanks @mbabker for the explanation. Nice!

There is another PR which already proposed the empty extending class, see #3629. However that one fails the unit tests. Probably because we then have the class alias and the real JRegistry class at the same time. Which sure isn't ideal.

I think we will have to change the class sooner or later anyway to the namespaced Registry class. We can do it now or with 4.0. I think as long as it can be done in a BC way, we should do it rather now than later.

3rd party extensions obviously need to deal with it. 4.0 will have no JRegistry anymore, that's quite sure. However 3rd parties would already benefit from this PR as things like for example the plugin params would be detected correctly by the IDE.

I guess that somehow a @deprecated mark should be somewhere in the Joomla code for that class (even if ignored by the auto-loader) with a proper php-doc comment explaining it's aliased elsewhere but deprecated in 3.3 and removed in 4.0, so that third-party developers get the proper depreciation warning and clear replacement instructions, and not a sudden freeking fatal non-existing class error in their IDE. But that was in reaction to my own "wtf happened with JRegistry, it's suddenly not existant anymore without deprecation, even in Joomla". I guess any professional developer using a decent IDE would have a similar reaction, which isn't ideal for the new 3.x-backwads-compatibility message. I think that @deprecated php-doc comments should have each time a clear instruction for the replacement, which often isn't the case, sometimes there even isn't a new way to do things. But that's my own opinion.

I don't have hard feelings here, so, PLT, do like you want (Joomla to be perceived by professional developers).

For my extensions, I have decided to use my own namespaced registry class where my extensions don't depend on Joomla's JRegistry (and its changes), so I don't see those sudden warnings anymore, nor other developers who take a look at my new code see them, so they don't get that bad "wtf is this sh.." moment.

I agree that a deprecation message would be great, but I don't know how it could be done.
I think it's one of the cases which need to be taken care of in the doc page when 4.0 is released and JRegistry is likely removed.

Of course if someone has a good idea how to add a log entry or a deprecation doc-bloc it's appreciated.

So far the best way I see is to add proper doc-blocs now which indicate what class is expected by a function and which it will return. That will at least notice the developers who read the cms source code occasionally.

@Bakual wrote:

Of course if someone has a good idea how to add a log entry or a deprecation doc-bloc it's appreciated.

Just add these lines in a file:

/**
 * @deprecated 4.0 Use \Joomla\Registry\Registry instead
 * @see \Joomla\Registry\Registry
 **/
class JRegistry extends  \Joomla\Registry\Registry
{
}

In e.g. a new deprecatedclasses.php file inside the Joomla library/joomla folder. Any reasonable IDE (i'm sure for 2 of them, and almost sure for 2 other ones) will pick that up and show the deprecation warning message at each use of JRegistry inside Joomla and 3rd party extensions. That's what Matt @betweenbrain proposed too for the git repo but not for releases. As most developers don't run off git but on realeases, I would recommend to add it to joomla releases as I just suggested. But that's of course PLT's decision on how they want to handle deprecation messages to Joomla developers.

@beat Ah, putting it into a file which isn't autoloaded but parsed by IDEs unlike the other PR which did it as a real JRegistry class. Yes that could work.
Can you do a PR for that?

I think it would still make sense to change the doc blocs (and later the other instances of JRegistry) like proposed in this PR. Do you agree with that?

Hi Thomas (@Bakual),

• Once PLT agrees with that proposal (and confirm that proposed location and filename library/joomla\deprecatedclasses.php sure I can do a PR.
• Yes, if the new fully namespaced use becomes the standard way (and i think that has been decided for all (?) classes in Joomla 4.0), and it is not considered as a break of new semver rules for 3.4, then it makes sense to change the uses and comments for that class throughout Joomla anyway imho.

@beat I don't feel strongly about this one way or another. If having those files in the releases is the best way to communicate a deprecated status to developers, then so be it.

I have to say I agree with beat in this case (with my extension developer hat on).

Although can we just shove this in the legacy folder rather than Joomla folder please?

Does it even have to be in a libraries subfolder? I think the libraries folder itself would make most sense to me. Similar to the classmap file we have there. I think if we go this route, there may be more such classes in future and they will not originate from the same subfolder.

it is not considered as a break of new semver rules for 3.4,

How could it be a break of the semver rules? Everything should work exactly as before since an alias actually makes the origin and alias class identic. Not like when you extend a class.
Or do you see how something could break?

Closing in favor of #4188 and related PRs which do the same and more.