`local self` will be overridden by scoped self... use some other local, like `local SkullMe = SkullMe` ... hell there's very little reason to have the addon in the global scope in the first place, especially come 3.3 which we may have tomorrow.
local SkullMe = SkullMe has the same performance as self when referenced?...Or am I negating the performance upgrade by wrapping it in a function.
Im not quite sure why im going thru all this this make a addon that already doesn't run alot faster but aww well. Its done feature wise so this is whats left.
Wikipedia has some good quotes about program optimization
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified[6] - Donald Knuth
Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you have proven that's where the bottleneck is. - Rob Pike
The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet. - Michael A. Jackson
local SkullMe = SkullMe has the same performance as self when referenced?...Or am I negating the performance upgrade by wrapping it in a function.
Im not quite sure why im going thru all this this make a addon that already doesn't run alot faster but aww well. Its done feature wise so this is whats left.
Variable names are arbitrary. You could put local gfhighfhljdgf = SkullMe and get the same performance.
Okay so im probably going to get 50 lashes with a wet noodle for asking this. If im going to set a local SkullMe, Can't I just rename it self while im at it?...Anywhere self would be used in my code and it isnt defined it would default to my file scope local.
You certainly can do that. But it would just cause you debugging nightmares when the "self" you expect isn't the "self" you get.
Suppose you did this:
a = {}
local self = a
function a:bar()
print("bar")
end
function a:blah()
print(self.var) -- WARNING: self refers to frame f when the event fires
end
f = CreateFrame();
f:SetScript("OnEvent", a.blah)
f:RegisterEvent("PLAYER_ENTERING_WORLD")
f.somevar = 10;
When PLAYER_ENTERING_WORLD fires, it will print 10, the "self" in a:blah() would refer to the frame "f", and not the table "a" because the first variable passed in is the frame itself. That is,
a.blah(f, "PLAYER_ENTERING_WORLD")
is called. Note the difference between : and . when calling functions. If you tried call self:Bar() inside a:blah(), it will fail with some error about not finding ["Bar"] in frame f.
I can't seem to be able to quote DathRarhek's quotes from wikipedia but, the first optimization that should be done to 100% of code is to make it good clean unambiguous code free of hacks. Doing 'local self = SkullMe' would be a hack that makes it harder to understand the code.
All of those quotes are referring to a starting point of clean unambiguous hack free code. If you showed any of those programming experts some of the crap code being used by some of the high popularity addons and said 'but there's nothing wrong with performance so it doesn't need changed' I would hope you get slapped.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Im not quite sure why im going thru all this this make a addon that already doesn't run alot faster but aww well. Its done feature wise so this is whats left.
With other words, don't worry too much.
Variable names are arbitrary. You could put local gfhighfhljdgf = SkullMe and get the same performance.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou certainly can do that. But it would just cause you debugging nightmares when the "self" you expect isn't the "self" you get.
Suppose you did this:
a = {} local self = a function a:bar() print("bar") end function a:blah() print(self.var) -- WARNING: self refers to frame f when the event fires end f = CreateFrame(); f:SetScript("OnEvent", a.blah) f:RegisterEvent("PLAYER_ENTERING_WORLD") f.somevar = 10;When PLAYER_ENTERING_WORLD fires, it will print 10, the "self" in a:blah() would refer to the frame "f", and not the table "a" because the first variable passed in is the frame itself. That is,a.blah(f, "PLAYER_ENTERING_WORLD")
is called. Note the difference between : and . when calling functions. If you tried call self:Bar() inside a:blah(), it will fail with some error about not finding ["Bar"] in frame f.
Remember that calling
a:blah("PLAYER_ENTERING_WORLD")
is the same as
a.blah(a, "PLAYER_ENTERING_WORLD")
All of those quotes are referring to a starting point of clean unambiguous hack free code. If you showed any of those programming experts some of the crap code being used by some of the high popularity addons and said 'but there's nothing wrong with performance so it doesn't need changed' I would hope you get slapped.