Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Style: Purge .compat.inc files #99517

Closed
wants to merge 1 commit into from

Conversation

Repiteo
Copy link
Contributor

@Repiteo Repiteo commented Nov 22, 2024

I very, very strongly dislike the use of .compat.inc files. They exist as files dedicated to a handful of function implementations that aren't even wholly separated because they have to be initially declared in header files. From where I sit, it makes much more sense to handle these functions in their respective implementation file, as we're already doing in their headers. I don't have any concrete or objective resources to back this up, it's really as simple as me not liking them to the extent that I made a PR entirely out of spite

@KoBeWi
Copy link
Member

KoBeWi commented Nov 22, 2024

These files allow for clearer separation of compatibility code.
I'd actually go in opposite direction and do more of that (#89160).

it makes much more sense to handle these functions in their respective implementation file, as we're already doing in their headers.

They are in the headers only because it's the only way.

@Repiteo
Copy link
Contributor Author

Repiteo commented Nov 22, 2024

They are in the headers only because it's the only way.

Ehh, not entirely. We've seen other headers use .inc files to define logic as if they were in headers; the most obvious example being bvh_tree.h. I'd be MUCH more open to the idea of these files if the headers got the same treatment. Hell, you could probably make dedicated #ifdef <HEADER_NAME_H> defines to have that same file handle header and implementation logic

...Shit, I might've talked myself into this

@akien-mga
Copy link
Member

akien-mga commented Nov 22, 2024

...Shit, I might've talked myself into this

Let me put a blocker here for now. This needs to be discussed with maintainers before doing more significant work there.

This kind of change shouldn't be done on a whim for personal taste reasons. There's a reason why we designed a system with separate files for compat code.
You would need to look up that reason before deciding to yank it.

Edit: I dug up through the history for this which wasn't obvious to find. This was designed in #76577, you'll need to expand some of the resolved discussions to see it.

I'm pretty sure there was more discussion spread across Rocket.chat and some issues, but yeah at this point tracking it down is a bit of investigative journalism work :P

But in short:

  • We want a clear separation of concern between the classes' intended API, and the legacy compatibility code. Using a separate file for this is a great way to make it so that developers and users don't need to bother about this code if they're not themselves adding compat breakages. In some cases it's a significant amount of deprecated code that needs to be kept for compatibility, and we're only 2 minor releases into using that system, more will accumulate over time.

See e.g. these examples from this PR:

 scene/animation/animation_player.compat.inc   |  76 ---------
 scene/animation/animation_player.cpp          |  48 +++++-
 scene/gui/popup_menu.compat.inc               |  81 ----------
 scene/gui/popup_menu.cpp                      |  53 +++++-
 servers/rendering/rendering_device.compat.inc | 151 ------------------
 servers/rendering/rendering_device.cpp        | 123 +++++++++++++-

Adding 123 lines of code to rendering_device.cpp that are not relevant for the current workings of this class is just adding more code that developers need to ignore or somehow load in their mental model when working on the class (and this will keep increasing, there are more compat breakages in the pipeline, and some more complex to handle than just a oneliner redirection method).

  • Eventually, if we move to 5.0, we'll want to drop all this compatibility code. Having it well self-contained in .compat.inc files is a nice way to find what code should be removed.

  • .compat.inc files included in the .cpp were chosen to avoid increasing build time, so this is just injecting some code in the .cpp - we keep concerns separate but don't have to pay extra for it in build time.

  • This system is now well established, documented, and I don't understand why it's so bad that it would need to be undone. This seems like a pointless refactoring to me.

  • I don't claim the current system is perfect and can't be improved though - apologies for my strongly worded initial reaction. It mostly comes from thinking that we have higher priorities to tackle than refactoring things that work fine.

Copy link
Member

@akien-mga akien-mga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This goes against our agreed guidelines with no good objective reason.

@Repiteo
Copy link
Contributor Author

Repiteo commented Nov 22, 2024

You know what, that's entirely reasonable. I might not entirely agree, but their reason for existing being laid out makes a lot of things "click". Closing.

@Repiteo Repiteo closed this Nov 22, 2024
@Repiteo Repiteo deleted the style/purge-compat-inc branch November 22, 2024 10:20
@Repiteo Repiteo removed this from the 4.x milestone Nov 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants