I know that changes to core logic are frowned upon at this stage, but what about changes to access modifiers?
Specifically, changing private variables/methods to protected (and virtual in some cases) to make the class more extensible.
Extending component classes
- DunnyOfPenwick
- Posts: 275
- Joined: Wed Apr 14, 2021 1:58 am
- Location: Southeast US
- pango
- Posts: 3359
- Joined: Wed Jul 18, 2018 6:14 pm
- Location: France
- Contact:
Re: Extending component classes
Well, it has been done numerous times in the last year or so...Specifically, changing private variables/methods to protected (and virtual in some cases) to make the class more extensible.
(But actually, when you make implementation details more visible, you're tying other classes to implementation details and make the original class much harder to modify(*). From a software engineer perspective just exposing all core logic for overloading by mods is terrible, it explains some mods breakage and a lot of mods conflicts.
But it's much easier/faster than carefully designing interfaces without knowing beforehand how modders will want to extend code, and we're not driving nuclear plants, so I guess it can still make sense)
Mastodon: @pango@fosstodon.org
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart
- DunnyOfPenwick
- Posts: 275
- Joined: Wed Apr 14, 2021 1:58 am
- Location: Southeast US
Re: Extending component classes
The reason I ask is I'm working on two related mods that requires me to override a couple of core classes with extended versions.
Currently it's just EnemySenses and FPSWeapon, but there might be a few more before I'm finished.
If I issued a pull request with the access modifier changes, would it be accepted?
Currently it's just EnemySenses and FPSWeapon, but there might be a few more before I'm finished.
If I issued a pull request with the access modifier changes, would it be accepted?