Strangest thing, my GitHub account just got flagged...
... I guess that's why the travis tests didn't run after my last commit?

Never seen that one before...

However, I contacted GitHub support and things went back to normal within 20 minutes or so. 👍

If I remember right, the JInstallerManifest objects are supposed to map directly to the XML attributes in each extension types manifest. So the one where you are changing from snake case to camel case, this should be done in the XML schema if required with compatibility proxies. The attributes where you are just changing case, it is fine since we are not case sensitive with these declarations.

Hmm, OK, there seems to be no snake case in the xml mappings, so this shouldn't be an issue, but I think we will need the proxies nevertheless if we want to (and we should) "standardize" camelCase on the xml files also. As of now, the xml files have mixed style tags.

Important update [1]: Well, it seems I picked just the right one to propose these kind of changes... 😸
So, with the current commit, everything works B/C, but doing a test with fixed cases in the XML-files will not. So, hold your horses for now. Will fix this, soon.
The backward compatibility issue when using corrected XML element names, is fixed now. (with da14e8e)

@frankmayer I believe you are right and that portion of the Coding standards is out of date. The example for that PHP code page is in mixed-HTML format rather than PHP

Private class members (meaning class members that are intended to be used only from within the same class in which they are declared) are preceded by a single underscore. Properties are to be written in underscore format (that is, logical words separated by underscores) and should be all lowercase.

I don't believe we follow the single underscore for Private class members anymore since that was more of a php 4 convention and I believe the Properties should be camelCase following the rest of the naming convention.

One thing to watch out for in fixing the snake_case to camelCase naming, is some of those are long-standing names in the database architecture. There has been resistance to fixing those since it will break 3rd party extensions.

@photodude

I believe you are right and that portion of the Coding standards is out of date. The example for that PHP code page is in mixed-HTML format rather than PHP

Not sure if it's only meant for mixed PHP/HTML as it mentions private class members and properties, which means that classes are involved.

I don't believe we follow the single underscore for Private class members anymore since that was more of a php 4 convention and I believe the Properties should be camelCase following the rest of the naming convention.

That is good to hear. Wasn't sure about this. When we have a confirmation on this, we should definitely change the docs on this.

One thing to watch out for in fixing the snake_case to camelCase naming, is some of those are long-standing names in the database architecture. There has been resistance to fixing those since it will break 3rd party extensions.

Yes, I know. That is why I wrote in the initial description:

This commit is a proof of concept for changing part of the "code standard hell" that exists at the moment, and at the same time, stay backward compatible. It would be great if Joomla 4.0 would be free of it. That would mean that we have to introduce new ones and deprecate(for 4.0) "wrong" property-names, in 3.x, so we can have a clean slate with 4.0.

If we manage to introduce the correct names in the 3.x line and provide BC then we can break BC in 4.0.
Note, that I am not talking on changing DB field names, here. Only the property names.

This PR also has to deal with issues with XML element names, on top of that 😄

I don't believe we follow the single underscore for Private class members anymore since that was more of a php 4 convention and I believe the Properties should be camelCase following the rest of the naming convention.

That is good to hear. Wasn't sure about this. When we have a confirmation on this, we should definitely change the docs on this.

FWIW, I think the only part of the code that HAS to retain the underscore notation is JTable. And that's in part thanks to how the database columns are directly set as class variables and a feature in its parent JObject class that treats underscored properties as non-public (so calling $table->getProperties() which does happen in JTable in a couple of places will filter out all of the underscored properties). And without changing the database schema to use camel case column names, you can't really do anything about snake case properties here.

@brianteeman I saw that you modified the milestone to 4.0. Wouldn't it be better to have these kinds changes done in the 3.9 line and deprecate them before 4.0? It would help to have a cleaner 4.0.

@frankmayer it was a mistake and I removed it directly afterwards

@brianteeman ah, yes, and I misread the notification in the timeline. Sorry to bother you. Have a nice day.

Can you rebase this one for 4.2 as we should deprecate now for version 5? It is is not applicable anymore for Joomla 4, please close the pr.