Closed SekoiaTree closed 3 years ago
I'll make another PR sometime to make final classes not final, but that's less important
I'm sorry, but... I don't really see the point in this?
What's a use-case for needing to modify/extend these classes/enums?
The API exists for a reason, to have a clean, defined way for external code to interact with the mod. Expecting other mods to work with internal classes just invites headaches IMHO. If there's an actual use-case here, please let me know, and I'll be happy to talk about extending the API to support it.
Unless there's a compelling reason for this I'm not seeing?
The main reason for this is for modules that extend the functionality of existing ones. I am currently making a mod that adds upgraded versions of all the modules, and for the execution module, I wasn't going to rewrite the whole code. Instead, I just mixined (since I couldn't extend due to it being final) and added a property for my parameters. I needed to set the state, though, which meant doing this. The main reason is "why not". It makes mixins easier, and doesn't make anything worse
I agree that it's a pretty small usecase, and it means I have to depend on :dev. However, I don't think you could really expose every single module and all their class as well as casings and controllers, since that essentially means exposing the whole mod to the api.
Oh. Interesting. I certainly didn't expect that, haha. Hmm, all right!
Nice, thanks!
Make private enums public, for additions (makes mixins easier) We have ways to access private inner classes, but not private inner enums. This makes this miles easier.