Alternative library classes which allows components (and other extensions) not using deprecated JError/JObject

[Izhar Aazmi]

For example the JTable, JModelLegacy, JControllerLegacy etc are still using JError / JObject  which leads to mixed JError and Exception handling usage.

I wonder if it is feasible to have a separate set of library classes so that the newer extensions can be based on, without depending on these deprecated classes/methods? 

I understand that some classes like JEvent etc are not very easy and even impossible to get rid of so soon. Still we can work on providing support so that usage of deprecated stuffs are actually discouraged as possible extent.

I can myself start working on this but I thought of making sure whether any work is already in progress or this is even feasible at all. I am also not aware of the planned prospects of successor classes for the said legacy classes (model, controller etc).

The same applies for the deprecation of $_abc properties being renamed to $abc in various classes. Can we have the two property values in sync so that we don't force people to still use the old way, despite being deprecated.

Not providing independent alternatives almost kills the advantage of the deprecation stages, which was actually meant for the developers to have enough time to switch to new recommended way.

[Bakual]

You mean like the already existing "New MVC" classes which are rarely used?

Imho, we should look what will be in J4 and then backport those classes to J3 if possible so they can be already used.

[Izhar Aazmi]

Yes, I mean almost the same. 

In fact, I mean anything that we want the people to be eventually using instead of the deprecated ones should be made usable indeed. There can be any reason that makes them unusable, such as:

1. incomplete or incompatibility of the new classes with the rest of the core.

2. Inadequate documentation on the new classes.

3. No usage in the core extensions, so that one can take hints.

Back-porting is the good idea when provided with sufficient interoperability, however I guess this route may take more time and we can expect it not earlier than now J3.7.

My top list is the JError and JObject usage that is not willing to leave us anyway.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Johan Janssens]

JError is best replaced by plain PHP Exceptions.  Here is a related PR for our Joomlatools Platfrom to give you an idea how we did this: https://github.com/joomlatools/joomlatools-platform/issues/165

We also created a legacy package that includes all the legacy classes that are not used by the Joomla core. Might give you an idea what code you shouldn't use in your own extensions. See: https://github.com/joomlatools/joomlatools-platform-legacy

Johan