Extending component classes

Discuss coding questions, pull requests, and implementation details.
Post Reply
User avatar
DunnyOfPenwick
Posts: 275
Joined: Wed Apr 14, 2021 1:58 am
Location: Southeast US

Extending component classes

Post by DunnyOfPenwick »

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.

User avatar
pango
Posts: 3347
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Extending component classes

Post by pango »

Specifically, changing private variables/methods to protected (and virtual in some cases) to make the class more extensible.
Well, it has been done numerous times in the last year or so...

(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

User avatar
DunnyOfPenwick
Posts: 275
Joined: Wed Apr 14, 2021 1:58 am
Location: Southeast US

Re: Extending component classes

Post by DunnyOfPenwick »

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?

Post Reply