I actually wrote that hooking code. The issue with your hook is that if the library was upgraded three time, it would add the hook overhead three time.
Could you elaborate why "[the hook] is not safe if the original function is changed in the future" and how your own code avoid this ?
local o = orig
function orig(...) -- handle all args
-- do your shit
return o(...) -- fall back to the original if your code didn't return out, handle all args and returns
end
Yes, it's unlikely that the function will ever change, but you should ALWAYS hook like this to ensure your hook is 100% safe. It's especially important to get new coders into this habit.
Well thats not entirely true. If you are in BG and not in raid or party it would cause the send message to fail, spamming the chat pretty terribly I experienced it with my raidvoice addon.
Oh right, this only recently cropped up didn't it? I don't really do comm in many addons anymore so I've never run into issues.
local o = orig
function orig(...) -- handle all args
-- do your shit
return o(...) -- fall back to the original if your code didn't return out, handle all args and returns
end
Yes, it's unlikely that the function will ever change, but you should ALWAYS hook like this to ensure your hook is 100% safe. It's especially important to get new coders into this habit.
Oh, so basically, the mixed up would be version:
-- Ensure to hook only once, even when upgrading the library
if not lib.OrigFunc then
lib.OrigFunc, OrigFunc = OrigFunc, function(...) return lib.MyFunc(...) end
end
-- This can be safely upgraded
function lib.MyFunc(...)
-- Do stuff
return lib.OrigFunc(...)
end
@Starouscz: here is another version that embeds the periodical voice activation timer as well as a very light comm protocol (though I suspect you won't like it :p) : http://paste.wowace.com/qo715xi9c3ljmdsz/
Possible enhancements could be :
- have the library automatically use Blizzard's push-to-talk key (it's stored in a cvar),
- have the library automatically do needed changes to Blizzard voice-chat settings when using voice activation.
Your timer is something very much alike i used in raidvoice before i switched to aceTimer. I think using ace timer is preferable here, because calling function 60 times per second is not very neat. Newertheless I included my version that supports both and has editable update period. Yes you are right i dont like your comm protocol i think i will stick to mine. In RaidVoice addon everything that starts with ! is a command and is dispatched as such and ignored if unknown, thats why i the test for ! is neccesery, everything else is displayed directly. I might have mentioned that these are not all comm commands i use.
I think using ace timer is preferable here, because calling function 60 times per second is not very neat.
There's no magic in AceTimer. It also calls a function on every frame (that is not always 60 times per second).
And please note the OnUpdate handler bails out early so it does not fully run on every frames but only every 2 seconds.
BTW, your comm handling logic if flawed : if the message is "", it will be treated as player name (because string.find("", "!") == null). IMO you should test for "", "!CLEAR" and nil as a first case.
And please get rid of semi-colons and inconsistent indentation.
You have gotten me wrong. I do not want to use ace timer in library, i want to let addon authors to use acetimer if they want, because then there is only one place where code (even if a few lines) is executed frequently.
Sorry about the code formatting if than is what you mean by identation, the code looks a bit different in my kwrite, maybe some sort of autoformatting of the paste? Anyway... http://paste.wowace.com/zp3cyql4g0i2nd1t/
Last I saw, you had a mixture of tabs and spaces for indention. Always use only tabs, then they are consistent and the user can set their preferred tab width.
I've always used monospaced fonts for coding and spaces for code indentation.
Using tabs always sounds nice on paper, but it never seems to work out well in practice for some reason if more than one person is contributing code. Probably it's because everyone likes to use different editors with different tab widths (or that use spaces instead of tab characters).
The main thing is to be consistent. Stick to one editor and make sure you know how it's handling tabs and indentation.
Mixing spaces and tabs for indentation always leads to disorder. Use a text editor that is able to stick to tabs, avoid using the spacebar to indent and everything goes fine. Ensure your coworkers do the same ; that's where coding convention comes into play. For now, we're editing using a textarea on paste.wowace.com, which is not really a text editor and where hitting the tab key just selects the next field.
I don't see how this would matter. 1 tab to my editor is 1 tab to yours, 2 to mine is 2 to yours, etc. Tab width doesn't make a difference.
True, but only if you're using them for start-of-line indentation, and only if you can force every code contributor to use spaces for indentation.
Tab width differences will still bite you if you're trying to make multiple columns of text.
People will also be lazy and let some editors default to using spaces instead of tabs when they hit the tab key (as many editors do these days), resulting in a mess when someone views the now mixed code with an editor set to a different tab width.
You have gotten me wrong. I do not want to use ace timer in library, i want to let addon authors to use acetimer if they want, because then there is only one place where code (even if a few lines) is executed frequently.
If it happens that several addons uses your library and all of them use AceTimer to do the voice check activation, the code will be run far more often that you'd like. Handling this inside the library ensure this won't happen.
Moreover, as an addon author myself, I'd expect that a library make my life simplier and doesn't require a lot of effort to make it working. Ideal I would just drop the file in my addon, load it from the ToC and have it working. That's especially true for libraries that provides optional features.
If it happens that several addons uses your library and all of them use AceTimer to do the voice check activation, the code will be run far more often that you'd like. Handling this inside the library ensure this won't happen.
Moreover, as an addon author myself, I'd expect that a library make my life simplier and doesn't require a lot of effort to make it working. Ideal I would just drop the file in my addon, load it from the ToC and have it working. That's especially true for libraries that provides optional features.
Fair enough.
I am still quite new to the concept of making wow addons and never bitter to learn a thing or two.
Then I have an other question, is it possible to see here at curseforge what projects use my library? I am curious to see what addons will accept it.
It does for wowace projects when the addon author uses the site .pkgmeta feature or manually lists the library as a dependencies of his project. This should also work for curseforge projects.
local o = orig
function orig(...) -- handle all args
-- do your shit
return o(...) -- fall back to the original if your code didn't return out, handle all args and returns
end
Yes, it's unlikely that the function will ever change, but you should ALWAYS hook like this to ensure your hook is 100% safe. It's especially important to get new coders into this habit.
Oh right, this only recently cropped up didn't it? I don't really do comm in many addons anymore so I've never run into issues.
With the patch 3.2 the hell broke loose ;)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOh, so basically, the mixed up would be version:
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumPossible enhancements could be :
- have the library automatically use Blizzard's push-to-talk key (it's stored in a cvar),
- have the library automatically do needed changes to Blizzard voice-chat settings when using voice activation.
http://paste.wowace.com/bu45qyi0htvkwdml/
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou should not use AceTimer in a library for the very same reason you should not use AceComm : no dependencies between libraries.
There's no magic in AceTimer. It also calls a function on every frame (that is not always 60 times per second).
And please note the OnUpdate handler bails out early so it does not fully run on every frames but only every 2 seconds.
BTW, your comm handling logic if flawed : if the message is "", it will be treated as player name (because string.find("", "!") == null). IMO you should test for "", "!CLEAR" and nil as a first case.
And please get rid of semi-colons and inconsistent indentation.
Sorry about the code formatting if than is what you mean by identation, the code looks a bit different in my kwrite, maybe some sort of autoformatting of the paste? Anyway...
http://paste.wowace.com/zp3cyql4g0i2nd1t/
Using tabs always sounds nice on paper, but it never seems to work out well in practice for some reason if more than one person is contributing code. Probably it's because everyone likes to use different editors with different tab widths (or that use spaces instead of tab characters).
The main thing is to be consistent. Stick to one editor and make sure you know how it's handling tabs and indentation.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI don't see how this would matter. 1 tab to my editor is 1 tab to yours, 2 to mine is 2 to yours, etc. Tab width doesn't make a difference.
True, but only if you're using them for start-of-line indentation, and only if you can force every code contributor to use spaces for indentation.
Tab width differences will still bite you if you're trying to make multiple columns of text.
People will also be lazy and let some editors default to using spaces instead of tabs when they hit the tab key (as many editors do these days), resulting in a mess when someone views the now mixed code with an editor set to a different tab width.
Not if you do it correctly. If you do it right, tab width never matters. Tabs for indention, spaces for alignment. It's that simple.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis. (Though I could not found indention in a dictionary :p)
Back to the topic:
If it happens that several addons uses your library and all of them use AceTimer to do the voice check activation, the code will be run far more often that you'd like. Handling this inside the library ensure this won't happen.
Moreover, as an addon author myself, I'd expect that a library make my life simplier and doesn't require a lot of effort to make it working. Ideal I would just drop the file in my addon, load it from the ToC and have it working. That's especially true for libraries that provides optional features.
Fair enough.
I am still quite new to the concept of making wow addons and never bitter to learn a thing or two.
Then I have an other question, is it possible to see here at curseforge what projects use my library? I am curious to see what addons will accept it.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumhttp://paste.wowace.com/bvnas01d5l8zxwcj/
Any comments?