As per deprecation notice it should be removed and replaced with stdclass

But it is not a drop in replacement so ther is more work that need to be done than just removing that class

that will break all xtd-buttons, which will need to be rewritten...

Correct and the updater is also extending JObject

Anything relying on its error handling capabilities should be refactored to use native PHP 5 error handling mechanisms (as in STOP USING JError ALREADY)

Anything using it as a data store either should be replaced with stdClass or a Registry object; part of it I believe is going to depend on how the objects are used and the keys the object uses.

Native PHP doesn't allow a property named core.create, so instead of $object->core.create you have to use $object->{'core.create'}. Stuff already looking for data in object notation would probably be best suited to go from JObject to stdClass but you need to account for the key names and make changes appropriately.

Registry implements ArrayAccess so its data is accessible in array notation, but not object notation. But, it does have get/set with similar APIs as JObject. Its difference though is how the data is stored; JObject essentially creates object properties for each key whereas Registry uses an internal a key-value store.

This part answers using JObject as a data store. All of that hasn't covered using it as the base class for a lot of the API.

Anything subclassing JObject basically gets a lot of lazy magic. You don't have to declare class properties, give them proper scope, handle their access or storage, and has a bit of an error handling mechanism in place (see the long outdated JError). Using JControllerLegacy as an example, one could easily do something like JControllerLegacy::getInstance()->get('views'); to access the protected $views property and get all of the JViewLegacy objects the controller is aware of through that property. Totally legal with the existing API. A more common use of it though is in accessing the properties of a JUser object, and there have been issues reported on that object when protected property data changed yet someone was using it because it is accessible through the JObject API (the only way to block it is to privatize all your class properties). That part's going to be tricky to deal with.

All that to say, I very much doubt it's going anywhere in 4.0. I'd almost be willing to bet it lives into 5.0 too. Like JError, it is deeply tied into the internal APIs of a lot of base classes (MVC layer, JTable, the updater library, and JUser), and for at least the MVC layer and JTable to stop extending from it they'll either need to inline the error handling properties or fully refactor to a non-JError based handling mechanism.

Thanks @mbabker!

Just to close off, some of the inheritance from JObject has already gone away in the 4.0 branch (JInstallerAdapter, JEditor, JAuthentication, JCaptcha, and JControllerLegacy being a few examples). The controller one will be interesting to see if it stays that way or gets reverted simply because that one potentially affects so much code; the others are more isolated classes and the odds those were being used with the JObject API is more minimal. I do intend on breaking the inheritance in JInstaller as well depending on how tight of a code coupling there is to that (I know some of the adapters make use of the JObject API to push data back to the installer, so it's a little trickier). Either way it's going to be a drawn out process.

Basically we're going to remove it as we can. But as Michael says it's unlikely we'll be able to fully remove it - especially in JTable and JModelLegacy....

if talk only about xtd-buttons, it simply can be replaced with Registry, without B/C, I think.