Road-block
commented
2 years ago I'll rebase but it being holidays I got sporadic time.
It's not an anti-pattern, the actual addon name is in a sense unique for a player's addon collection (you can't have 2 addon folders named both "MyAddon" in your AddOns folder).
It still doesn't prevent a misbehaved different addon to overwrite your globals. It is good practice in general to limit the footprint of your addon in the global namespace (ideally only its saved variables and any objects / API you specifically want to make accessible from the outside)
That vararg passed in by the wow client to all the lua files of an addon that the toc loads is an elegant solution to sharing variables/data between the files of your addon without having to put them in the global namespace where another addon can shadow them or overwrite them (addon conflicts are usually the most annoying to debug and reproduce).
You can expose your main addon object by making it global to facilitate debugging your addon but in the case of Ace3 addons you don't need to, you can always LibStub("AceAddon-3.0"):GetAddon("YourAddonName") to retrieve your addon object and run its methods.
Take the example of your CommPrefix variable. In your current implementation that was a global. If another addon declares a CommPrefix variable after your addon has loaded, it's breaking yours (and vice versa) if you load after a different addon that declares a CommPrefix variable in the global namespace.
Using_the_AddOn_namespace gives a quick overview.
SabreValkyrn
Oh, this is interesting. Using the namespace passed in by the client does seem more efficient than a new global with a local reference.
I've seen the current pattern in a few addons
Is that an anti-pattern then? Seems usually with Ace3 addons.
Looks like this needs a rebase now after #22. I should have merged this in first then mucked with my own changes, but didn't see this until afterward.