I'd like to include the ability to activate some actions based on 'triggers', i.e. certain zone names/types, party type, gear swaps pvp status etc etc. I wonder if a library for this purpose exists and if not whether it would be worth it to create one.
For (contrived) example,
addon = LibStub("AceAddon-3.0"):NewAddon("Addon", "LibTrigger")
addon:RegisterTrigger(addon:Trigger('zone', 'the storm peaks'):And('pvp', true), function() print('PvP on in the Storm Peaks!?') end)
I doubt it would be worth it, you're just creating a wrapper around the current events and API... you wouldn't gain anything, you'd just add extra unneeded code. Site down and write out the proper lua to handle whatever it is you need handled.
... you're just creating a wrapper around the current events and API...
Quote from Adirelle »
...but there is so much things to test that it could quickly get bloated.
While I agree with both of these sentiments I think a point could be made that while everyone writes the lua for their events total bloat is increased. These sorts of triggers occur in a lot of addons and perhaps would occur in many more or in a more advanced and customisable way if a time saving and simpler way of accessing the events that also offered a convinient way of exposing the configuration of the triggers in a front-end were available.
One added value could to handle those pesky cases where API return values are inconsistent when some events trigger (e.g. how the returned zone names may be outdated when the ZONE events fire).
While I agree with both of these sentiments I think a point could be made that while everyone writes the lua for their events total bloat is increased. These sorts of triggers occur in a lot of addons and perhaps would occur in many more or in a more advanced and customisable way if a time saving and simpler way of accessing the events that also offered a convinient way of exposing the configuration of the triggers in a front-end were available.
No it would be total bloat. You only code what you need when you aren't using a library and your idea included so many different types of triggers that it would be total bloat fest.
You only code what you need when you aren't using a library and your idea included so many different types of triggers that it would be total bloat fest.
I think that 'bloat' is a very odd way to describe functionality. I suspect that often authors that implement situational changes don't explore the full range of options that users may find useful because they'd rather be spending time on the rest of their, more interesting, code. And how much bloat are we talking here, a hundred k or so of memory?
I'm also not at all sure I'm going to make it. If and when I implement 'triggers' in my addon I may as well do so in as modular and reusable way as possible if only just for my own purposes. After all, it's wanting to be able to just type code much like in my example that prompted me to look for such a library in the first place.
I suspect that often authors that implement situational changes don't explore the full range of options that users may find useful...
Just becausee it may be useful doesn't mean you need to offer it. It's often better to program directly for the most common use cases and get that right rather than just give the user every option under the sun. If you get the right cases, you don't have to implement *every* case, and it's actually easier on the user.
I think there would be better ways to talk "bloat" but for the most part it would not use that word, rather instead talk about utility, frequency of use, performance, load time, code reuse, modulatity etc etc...
But back to LibTrigger, I think the right thing to do is go bottom up.
Work on triggers you need yourself. And if you think there is some tangible functionality worth sharing, share it. Likely you end up with a granularity of shared code that is more suitable than trying to do all triggers when most addons at best will want a select very few.
I'd like to include the ability to activate some actions based on 'triggers', i.e. certain zone names/types, party type, gear swaps pvp status etc etc. I wonder if a library for this purpose exists and if not whether it would be worth it to create one.
To answer your specific question, it is unlikely 2 addons that a user is running would ever need the same trigger or even the same type of triggers you are thinking of.
As such, writing a library for it is meaningless, in the sense that library code is meant to be shared among multiple addons, but if less than 2 addons are likely to be using the same library (and the probability of those 2 addons installed and both running at the same time), then why even make it a library with additional callback overheads (with xpcall or pcall and all)?
An example of such a library, would be one that say, BigWigs and DBM could share (such as boss detection triggers). But no user would likely run both those addons at the same time, so writing a more generalized library for it is a bad idea. Same with say GatherMate and Gatherer, a library to detect known herbs.
I did not expect such a library to be a massive memory saver but more an author time saver by providing a logical and quick way of expressing combinations of events and by offering to automatically generate a configuation UI for user-customisable triggers. Several addons I use implement this kind of functionality and all of them have one or two draw-backs such as not being able to combine triggers or being limited by their quantity or completeness.
Either way, I'll implement what I have in mind for my own purposes and if I think it's worth sharing I'll try to do so.
Either way, I'll implement what I have in mind for my own purposes and if I think it's worth sharing I'll try to do so.
Another solution is too implement it as your "private" library, i.e. take the advantage of a library form using LibStub but do not distribute it standalone nor create a wowace project, just embed it in your addons.
There is also an inherent problem with all libraries, where if other authors use your library, you have an obligation to maintain and keep it updated. Similarly, if you were to use someone's else library, you would expect that library to be maintained.
This is where commitment comes in, where creating a library isn't just a matter of sharing code, but also committing to keeping it updated, or looking for people to take over should it become necessary.
If you go with say Adirelle's suggestion, an internal library that isn't distributed standalone, then this wuuldn't be an issue since such a library would just be for your own addons' use, but not really meant for external author use (although other authors could contact you about it, put a note in the source code).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
For (contrived) example,
addon = LibStub("AceAddon-3.0"):NewAddon("Addon", "LibTrigger")
addon:RegisterTrigger(addon:Trigger('zone', 'the storm peaks'):And('pvp', true), function() print('PvP on in the Storm Peaks!?') end)
Thanks,
Dan.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhile I agree with both of these sentiments I think a point could be made that while everyone writes the lua for their events total bloat is increased. These sorts of triggers occur in a lot of addons and perhaps would occur in many more or in a more advanced and customisable way if a time saving and simpler way of accessing the events that also offered a convinient way of exposing the configuration of the triggers in a front-end were available.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNo it would be total bloat. You only code what you need when you aren't using a library and your idea included so many different types of triggers that it would be total bloat fest.
I think that 'bloat' is a very odd way to describe functionality. I suspect that often authors that implement situational changes don't explore the full range of options that users may find useful because they'd rather be spending time on the rest of their, more interesting, code. And how much bloat are we talking here, a hundred k or so of memory?
I'm also not at all sure I'm going to make it. If and when I implement 'triggers' in my addon I may as well do so in as modular and reusable way as possible if only just for my own purposes. After all, it's wanting to be able to just type code much like in my example that prompted me to look for such a library in the first place.
Just becausee it may be useful doesn't mean you need to offer it. It's often better to program directly for the most common use cases and get that right rather than just give the user every option under the sun. If you get the right cases, you don't have to implement *every* case, and it's actually easier on the user.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorThat is exactly the term used when a piece of software contains a plethora of functionality that, for the most part, won't be utilized by every user.
But back to LibTrigger, I think the right thing to do is go bottom up.
Work on triggers you need yourself. And if you think there is some tangible functionality worth sharing, share it. Likely you end up with a granularity of shared code that is more suitable than trying to do all triggers when most addons at best will want a select very few.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumTo answer your specific question, it is unlikely 2 addons that a user is running would ever need the same trigger or even the same type of triggers you are thinking of.
As such, writing a library for it is meaningless, in the sense that library code is meant to be shared among multiple addons, but if less than 2 addons are likely to be using the same library (and the probability of those 2 addons installed and both running at the same time), then why even make it a library with additional callback overheads (with xpcall or pcall and all)?
An example of such a library, would be one that say, BigWigs and DBM could share (such as boss detection triggers). But no user would likely run both those addons at the same time, so writing a more generalized library for it is a bad idea. Same with say GatherMate and Gatherer, a library to detect known herbs.
Either way, I'll implement what I have in mind for my own purposes and if I think it's worth sharing I'll try to do so.
Thanks again,
Dan.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAnother solution is too implement it as your "private" library, i.e. take the advantage of a library form using LibStub but do not distribute it standalone nor create a wowace project, just embed it in your addons.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis is where commitment comes in, where creating a library isn't just a matter of sharing code, but also committing to keeping it updated, or looking for people to take over should it become necessary.
If you go with say Adirelle's suggestion, an internal library that isn't distributed standalone, then this wuuldn't be an issue since such a library would just be for your own addons' use, but not really meant for external author use (although other authors could contact you about it, put a note in the source code).