WoWInterface - Reusing Blizzard Code

WoWInterface (https://www.wowinterface.com/forums/index.php)

- AddOn Help/Support (https://www.wowinterface.com/forums/forumdisplay.php?f=3)

- - Reusing Blizzard Code (https://www.wowinterface.com/forums/showthread.php?t=55975)

Reusing Blizzard Code

I'm curious how one reuses Blizzard's code in their addon. Is it through hooksecure or simply using the code as a base and they add their own code?

Can you be more specific? It entirely depends on what code, what it does, where it is, and what it affects. For example, I wouldn't "reuse" dropdown menu code because part of it causes taints when addons use it directly.

Quote:

Originally Posted by Kanegasi (Post 326510)

Sorry, I should have given an example. Dominoes, AFAIK, reuses action bar code,

Quote:

Reuse as much standard blizzard action button code as possible.

Quote:

I wanted to see how much I could do while maintaining compatibility with the standard action button code.

My memory is failing me, but I thought some nameplates, tool tips and unit frame addons try to do the same.

I hope this helps.

Ultimately, people do both ways. A better question would be, what are the advantages and disadvantages of each method?

(This is more of a rhetorical question on my part, btw)

In that case, it's more of a "don't reinvent the wheel" kind of thing. If an addon wants to replicate something Blizzard did, completely copying it is the best thing to do, as long as you change any globals in the reused code so it doesn't interfere with Blizzard's original code.

My second addon, Decliner, started almost three years ago by plopping in parts of code from addons I knew did what I wanted and I went from there. Barely any of the code is recognizable from what I started with.

My original reply was directed more at using active code ingame, especially code that has even one part protected.

As mentioned above, reuse of code is the fastest way to get things done. Is Blizzard's code good - maybe. Is Blizzard's code the best - definitely not. See, for example, how they implemented PaperDollFrame_SetVersatility:

Lua Code:

function PaperDollFrame_SetVersatility(statFrame, unit)
    if ( unit ~= "player" ) then
        statFrame:Hide();
        return;
    end
 
    local versatility = GetCombatRating(CR_VERSATILITY_DAMAGE_DONE);
    local versatilityDamageBonus = GetCombatRatingBonus(CR_VERSATILITY_DAMAGE_DONE) + GetVersatilityBonus(CR_VERSATILITY_DAMAGE_DONE);
    local versatilityDamageTakenReduction = GetCombatRatingBonus(CR_VERSATILITY_DAMAGE_TAKEN) + GetVersatilityBonus(CR_VERSATILITY_DAMAGE_TAKEN);
    PaperDollFrame_SetLabelAndText(statFrame, STAT_VERSATILITY, versatilityDamageBonus, true, versatilityDamageBonus);
    statFrame.tooltip = HIGHLIGHT_FONT_COLOR_CODE .. format(VERSATILITY_TOOLTIP_FORMAT, STAT_VERSATILITY, versatilityDamageBonus, versatilityDamageTakenReduction) .. FONT_COLOR_CODE_CLOSE;
 
    statFrame.tooltip2 = format(CR_VERSATILITY_TOOLTIP, versatilityDamageBonus, versatilityDamageTakenReduction, BreakUpLargeNumbers(versatility), versatilityDamageBonus, versatilityDamageTakenReduction);
 
    statFrame:Show();
end

A global CR_VERSATILITY_DAMAGE_DONE is used 3 times without being localized, CR_VERSATILITY_DAMAGE_TAKEN, STAT_VERSATILITY - 2 times. Global functions GetCombatRatingBonus and GetVersatilityBonus are used twice. Variable versatility is used only once, so instead of it the formula of it's calculation needs to be plugged in tooltip2.
Also, sometimes modifications needed for the code to behave the way you want are so great that one can start to wonder whether complete rewrite would be faster.
So can the Blizzard's code be reused - of course it can. But whether it should be reused depends by case.

Whether the code is good or not is closely tied to its age. A lot of the older code base is mostly unchanged and doesn't use things that came with Lua 5.1. There's also a lot of global lookup going on. I replicated the entire code for displaying the contents of quest reward frames and managed to cut the line count in half due to how inefficient it is. As features get added, it's not uncommon that they're spaghetti coded on top of old code, which makes things worse.

There's also a ton of weird stuff that's floating about because different developers have come and gone. For example, there's an entire OOP class abstraction layer which only seems to be used for tutorials.

Reusing code with side effects (affecting things outside the scope of the function) also has the consequence of spreading taint, so you should be careful anytime you want to reuse code.

This is what I like to do in many of my addons.

rButtonTemplate allows you to hook default aura, item and action buttons.
rActionBar allows customization of the default Blizzard actionbar.
Some goes for the minimap and many other things. The Blizzard code is just fine most of the time if you "bend" it a little.

The only thing that I cannot stand are unitframes/nameplates. I like to scrape them completly and use oUF.

I'd like to scrap the personal resource display and separate it from the nameplate system. It's such a clusterfuck.

Thanks for all the replies, it makes a lot more sense now. I thought in the past that Blizzard had looked at addons and sort of implemented their functionality in game. Have they ever hired an addon author? It seems that they could fix some of the code issues by working with authors and adopting their code. Of course that could mean one less addon, but I'd be thrilled if they ever used an addon that I wrote.

There is an IRC where wow devs and addon developers hang out. If there is a real bug with addon support / WoW API it gets fixed pretty quickly most of the time.