UnitID:GUID/GUID:UnitID Map

[pelf]

All of the addons that I have installed that need a UnitID:GUID map appear to implement it themselves. Is there a library for this at all? It seems like a prime candidate.

[Torhal]

It's just simple table-assignment and referencing. Unless you had some other sets of API in mind...

Also, there's this...

[myrroddin]

Originally Posted by Torhal Also, there's this...

Which, like many libraries, and a few AddOns with public APIs, needs a much better description or documented API page.

[pelf]

Originally Posted by Torhal LibGUIDRegistry

Looking at that library, it looks like at least one person had the same thought. I'm not sure I'm totally on board with some of his structural choices; but, given that it's not complete, there's no real way to know what was intended for everything.

Originally Posted by Torhal It's just simple table-assignment and referencing. Unless you had some other sets of API in mind...

Yeah, I think I understand what's involved, but if it's not centralized that means every single addon has to watch for those roster change and target change events and refresh their maps. If one library was doing that work for every addon, that would be a lot better, I'd think.

[Phanx]

Originally Posted by pelf Yeah, I think I understand what's involved, but if it's not centralized that means every single addon has to watch for those roster change and target change events and refresh their maps. If one library was doing that work for every addon, that would be a lot better, I'd think.

Not really. Let's say you need the GUIDs to attach combat log events to group units, so for each CLEU event you're looking up the provided GUID to find the associated unit. You can either (a) register for GROUP_ROSTER_UDPATE, call UnitGUID 10 times when it fires, and then perform a table lookup for each CLEU event, or (b) a library can register for GRU, call UnitGUID 10 times when it fires, and then your addon can call a library method for each CLEU event.

Given how much slower it is to call a function than to do a table lookup, I think you'd probably need to have a lot of addons needing this functionality in order for that to be a good tradeoff.

GRU only fires when a group member joins, leaves, dies, resurrects, moves between groups, or is promoted/demoted, so the overhead of even 10 addons calling UnitGUID 10 times per GRU event (and I think that's an unrealisitcally high number of addons, as I only have 1 addon + 1 library out of ~190 addons that are maintaining full unit/guid maps) is probably going to be lower than 10 addons calling a library function for every CLEU event.

[pelf]

What if you also factor in the other component of the map maintenance: the targeting events? Arguably, those are more important than the roster changes as they happen much more often and more overall.

[Phanx]

Well, either:

a) each addon responds to target events, calls UnitGUID, and updates the map; and then each addon performs a table lookup inside CLEU,

or:

b) the library responds to target events, calls UntiGUID, and updates the map; and then each addon calls a library function inside CLEU.

Again, I'd have to argue that 1 addon calling a function on target change + 10 addons calling a function inside CLEU is always going to be more expensive than 10 addons calling a function on target change + doing a table lookup inside CLEU. There's just no way that people in your group are changing targets more often than CLEU events are firing.

[SDPhantom]

It is entirely possible for a library to make available its lookup tables rather than force individual addons to call API functions that act as a proxy for such data. This would provide an equally fast lookup compared to the addon handling everything itself. The downside of this is that any addon can freely modify the table and corrupt the data stored.

[Phanx]

True, but like I said earlier -- out of the 170 addons I use regularly, only one addon (Grid) and one library (LibResInfo) maintain GUID maps. I just can't see anyone, especially the average user with far fewer addons, having enough addons using GUID maps where you'd see any difference at all by moving all of the GUID map code to a library.

Plus, even if you wrote such a library, since it's so trivial to maintain the map yourself, I think you'd have a hard time getting addon authors to bother use it, making it even less useful.

[SDPhantom]

The only real differences we're talking about here is memory usage. In an addon like Auctioneer which has databases to maintain in memory, we're still only talking about 25-30Mb. That's nothing in a bottom line system today that's running between 2-4Gb of RAM. As far as CPU impact, the target and roster events only fire a handful of times a minute. With that in mind, all we're seeing here is a few milliseconds of difference anyway. This is as Phanx was saying about there not being any real noticeable difference between having a library handle this or each addon maintaining their own GUID maps.

I myself don't use any libraries in my addons. Most if not all of my addons are simple enough, I don't need to complicate any of them by adding 3rd party code. I don't even use Ace, it's completely pointless. Everything I've seen of the Ace framework, I could easily do in my sleep and much more efficiently.

[Dridzt]

Originally Posted by SDPhantom Everything I've seen of the Ace framework, I could easily do in my sleep and much more efficiently.

Bold claims... but then I guess it also depends on the size determined by the 'seen' qualification.

[Phanx]

Originally Posted by SDPhantom Most if not all of my addons are simple enough, I don't need to complicate any of them by adding 3rd party code. I don't even use Ace, it's completely pointless. Everything I've seen of the Ace framework, I could easily do in my sleep and much more efficiently.

AceEvent and AceLocale are completely pointless; the entirety of AceLocale can be replaced by a one-line metatable definition. AceHook and AceTimer aren't hugely useful either, as hooking is trivial, and timing is pretty easy too. AceDB is mildly useful if you want to support multiple profiles. AceConfig and AceGUI are the only things that are useful; they're definitely bloated, but they're also really nice when you need dynamic options -- trying to write the entire config system for Grid with support for user-added auras, plugins, etc. using static widgets would be a nightmare.

(I can't really say anything about AceBucket, AceComm, or AceSerializer, as I've never used them or looked at them, though I'd guess that the first two fall more toward the AceEvent end of things than the AceGUI end.)

There are also some other libs that don't really add anything in terms of efficiency, but I use them purely for convenience -- LibPetJournal, for example, trivializes working with the pet journal and ensures that I'm not screwing up other addons, while LibResInfo trivializes identifying res targets and saves a lot of work and code for any addon using it.

However, a GUID map library wouldn't add any real efficiency, and wouldn't really save anyone much code or effort either, so it just seems pointless.

[SDPhantom]

AceComm is trivial too except maybe when sending messages larger than the standard size. I haven't seen anyone use AceSerializer to the point where it was necessary. Everything I've seen people send were single-dimensional tables. I've even coded a serializer using the exact same protocol that works much more efficiently. This was before I worked on my own serialization protocol that offered minimal overhead and much greater support for data structures. Last I checked, AceSerializer doesn't have support for detecting multiple references to a single table. Multiple references to a table results in duplicate data and if a circular reference is encountered, it sends Lua into an infinite loop.

[Rilgamon]

I consider the ace framework as a really good starter for beginners. The libs take the required stuff like the loading process out of sight and allow the beginner to concentrate on his project. Later in the learning curve one can replace them step by step. But as Phanx said some are really usefull GUI and SavedVariables-Handling are imho too good to not be used

[myrroddin]

Originally Posted by SDPhantom AceComm is trivial too except maybe when sending messages larger than the standard size. I haven't seen anyone use AceSerializer to the point where it was necessary.

I'm not looking for pros or cons, but when I wrote LibGuildBankComm, AceSerializer and AceComm were huge boons. Rather than reinvent the wheel, having them available took enormous work out of the library's code.

At any given point, LGBC sends or receives the contents of a guild bank page, the tab info, and gold. Sure, I could have designed code to serialize the tables, then send them over the addon comm, breaking them into chunks so the channel doesn't choke, but the wheel existed, so I used it.

Right, just to be clear, I am not debating whether Ace is good or bad; merely pointing out an example where it was, in fact, more useful than not having it in the first place.

[Torhal]

Can I help derail the thread? Please?

[SDPhantom]

Originally Posted by Rilgamon I consider the ace framework as a really good starter for beginners. The libs take the required stuff like the loading process out of sight and allow the beginner to concentrate on his project. Later in the learning curve one can replace them step by step. But as Phanx said some are really usefull GUI and SavedVariables-Handling are imho too good to not be used

The problem is, once you teach a beginner to use a library rather than showing them how to do something in the base API first, they become dependent upon the library and think of it as the only way to achieve a result. You give them a solution without letting them understand why the code works in the first place. Some libraries may be useful to others, but as a learning curve, they hide what a beginner needs to learn about the base API.

[pelf]

Yeah, derail aside, I think that most of you aren't the standard addon case. While I might have it in me to become proficient enough to write my own stuff, I'm not sure I'd ever be motivated to do that given that I spend 8 hours of each day, already, writing code at my job.

So, ignoring the fact that none of these addons would use this anyway, in the perfect world of all addons needing a GUID map using the same library (and, of the ones that I have installed, at least 3 of them maintain one; I stopped searching after I found three examples), one addon responding to the events, maintaining the map and exposing it to anyone who needed it still seems better...

That said, I'm not interested in making a library. I will just need to implement a GUID map at some point soon. I'll post back here if I have some questions. By all means, though, keep debating; this has been interesting to read.