Several Mixins use private variables to store any informations they need, like AceComm using self.commPrefix. But this could be also a name of a variable in my addon so I decide to use self.commPrefix = 'MyAddon' and doesn't realize that I break the usage of AceComm.
So as every Mixin uses private variables and authors use private variables too is it possible to make a decision how a Mixin should save the variables it uses? Sth. like "self._MixinAddon.foobar" instead of "self.foobar". So there are no conflicts between the Mixins variables and the variables I used in my addon and there aren't any possible conflicts of 2 or more mixins to each other.
Most addons uses self.vars.myvar to store it's running data. I've also seen self.const.myconst for constants. Looks to me like a good way to avoid conflicts.
The best thing to do is when you make a mixin/library is to be very careful with your pollution of the addon space. For example, don't create things like self.commPrefix, the name is just too common.
It is one of the reasons I renamed the aggro stuff for RosterLib to ".banzai" and stuff when I moved it from Squishy to BanzaiLib, so that other users of RosterLib do not accidentally reset BanzaiLibs saved properties on the user objects.
In any case, the use of self.var is slower than declaring it as a local in the addon, since it requires an additional table lookup, so generally speaking, if you're not trying to be object-oriented or need to expose the information outside your addon, you should simply use locals.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
So as every Mixin uses private variables and authors use private variables too is it possible to make a decision how a Mixin should save the variables it uses? Sth. like "self._MixinAddon.foobar" instead of "self.foobar". So there are no conflicts between the Mixins variables and the variables I used in my addon and there aren't any possible conflicts of 2 or more mixins to each other.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt is one of the reasons I renamed the aggro stuff for RosterLib to ".banzai" and stuff when I moved it from Squishy to BanzaiLib, so that other users of RosterLib do not accidentally reset BanzaiLibs saved properties on the user objects.
In any case, the use of self.var is slower than declaring it as a local in the addon, since it requires an additional table lookup, so generally speaking, if you're not trying to be object-oriented or need to expose the information outside your addon, you should simply use locals.