-
-
Notifications
You must be signed in to change notification settings - Fork 13
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
Make use of Ace3-addon to control addon lifecyle #97
Comments
The main question is, do we really need it? What does it improve exactly? AIO is/was a pretty small addon, I'm not sure I want to bring in even more of Ace3 if the gain is not that big |
Do we need it? Almost certainly not. Mostly the gains would be consistency and code reduction, at least in the context of matching the current functionality. On the surface, the thing we would gain would be the various number of utilities and features that become easily possible now that we're implementing an Ace3 addon object. So in a 1:1 implementation, it's functionally a draw between what we have now vs an Ace3 implementation, but it does allow us extensibility down the line and gives us less code to maintain overall. For example, I find Ace's database functionality to be really helpful, particularly with its internal de-duplication and callbacks. Likewise, if we were to use Ace3-db, we could then make use of profiles, which has been a commonly requested feature. Also, adding localization support would also be useful for non-English locales, which Ace3-locale would do cleanly. Lastly, for what it's worth, in my own projects by offloading a lot of the boilerplate tasks to Ace3, such as handling events, console commands, timers, communication, etc, it's insulated me greatly from needing to get hands-on between major patch updates. Anecdotally, it's made my addons much easier to maintain with less need for patching changes constantly. And its totally cool if you're not interested, it just seemed like a very straightforward implementation that keeps the AIO codebase focused on what it does best, and out of the business of implementing boilerplate addon cruft (as little as AIO does anyhow). |
I'm kinda scared of profiles and how backup/restore CVars systems works hrm. I'll think about it |
Sounds good. Feel free to take a look at my project Enhanced Raid Frames for an idea of how I'd likely implement it. https://github.com/brittyazel/EnhancedRaidFrames No pressure whatsoever, I just thought I'd throw the idea out there. |
Hi @Stanzilla,
Adding to the rest of the Ace3 work I was doing, it seemed like it wouldn't take too much work to restructure the addon as an Ace3-addon, which would provide us with some useful functionality with regard to managing the addon lifecycle. Likewise, we could then make use of of tools such as Ace3-event and Ace3-console. This could remove a bunch of boilerplate code, and reduce our dependency on the Eve library.
Likewise, if we can do this, future steps could me using Ace3-db for database management, and we could implement Ace3-locale for localization management.
Again, I'm happy to do this work, I just want to get the go-ahead before I make any sort of structural changes like this.
The text was updated successfully, but these errors were encountered: