Thread Tools Display Modes
12-23-09, 02:10 PM   #1
Sythalin
Curse staff
 
Sythalin's Avatar
AddOn Author - Click to view addons
Join Date: Aug 2006
Posts: 680
Not used to object based yet....

Can't test these things yet, but wanna see if I'm doing things correctly. Using DuctTape to learn (most code obviously cut):

dt.lua

Moreso, I'm worried about saved var declaration in the .toc:

Code:
SavedVariablesPerCharacter: DT.on
As the subject says, I'm getting used to object based lua and want to make sure I'm understanding it correctly.
  Reply With Quote
12-23-09, 04:02 PM   #2
Polarina
A Theradrim Guardian
AddOn Author - Click to view addons
Join Date: Aug 2007
Posts: 63
What's the question?

And the question is?
  Reply With Quote
12-23-09, 05:03 PM   #3
xConStruct
A Chromatic Dragonspawn
 
xConStruct's Avatar
AddOn Author - Click to view addons
Join Date: May 2008
Posts: 199
The basic principle is correct - moving all functions and important variables into your addon table. But there are some mistakes which prevent your code from working:

Code:
lines 4 and 17
yours: function DT:ADDON_LOADED(self, event, ...)
correct: function DT:ADDON_LOADED(event, ...)
If you write ':' instead of '.', you are already telling Lua that 'self' is expected as arg1, so you don't need to write it into the function argument list - just go on with arg2.

Code:
lines 19 and 33
yours: local DT.f = CreateFrame("FRAME")
correct: DT.f = CreateFrame("FRAME")
A table-entry cannot be declared local, because it is in the scope of the table. Just drop the local for table-values.

Code:
line 37
yours: DT.f:RegisterEvent("OnEvent", function(DT, event, ...) if DT[event] then return DT[event](DT, event, ...) end end)
correct: DT.f:RegisterEvent("OnEvent", function(self, event, ...) if DT[event] then return DT[event](DT, event, ...) end end)
Your function saves arg1 in 'DT' - and the event API passes the frame as arg1, so 'DT' becomes your frame and not the real DT-table you were expecting. Just replace the 'DT' in the functions arguments with 'self' and DT will still hold the upvalue DT-table.

Code:
lines 40 and 41
yours: ChatFrame_AddMessageEventFilter("CHAT_MSG_BATTLEGROUND", DT:filter);
correct: ChatFrame_AddMessageEventFilter("CHAT_MSG_BATTLEGROUND", DT.filter);
The ':' only works in conjunction with function calls, but AddMessageEventFilter expects to get a reference to a function. So, you just deliver the table-entry with a '.' and Lua won't complain. But this causes another problem: DT is not passed as arg1 when the function is called, so you cannot use 'self' in the function context and instead have to use the upvalue DT.

Some tips:
1) Do not try to store all variables in your tables, but only the ones which need to be accessed from other places (or different files). For example, dt.list could as well be just a simple 'local list'.

2) You could eliminate the whole dt.f-variable and the confusion concerning the event-function by just declaring your frame as the addons namespace, e.g. by writing 'DT = DT or CreateFrame("Frame")' on top of the file. Just remember: frames are tables, too

Last, but not least:
Do not 'enforce' object-oriented programming on all things you come across. Just do it where it makes sense, e.g. defining a global namespace for your important addon functions or passing 'self'. Local variables/functions still have their use and are not excluded by OOP. Just try to find a good balance

Good luck on your further scripting! OOP makes things a lot more structured and is imho more fun to write.
__________________
« Website | GitHub »

Oh hai!
  Reply With Quote
12-23-09, 07:20 PM   #4
Sythalin
Curse staff
 
Sythalin's Avatar
AddOn Author - Click to view addons
Join Date: Aug 2006
Posts: 680
Code:
lines 4 and 17
yours: function DT:ADDON_LOADED(self, event, ...)
correct: function DT:ADDON_LOADED(event, ...)
Ah, I forgot that x:function() == function(x).

Code:
lines 19 and 33
yours: local DT.f = CreateFrame("FRAME")
correct: DT.f = CreateFrame("FRAME")
Thanks, woulda missed that.

Code:
line 37
yours: DT.f:RegisterEvent("OnEvent", function(DT, event, ...) if DT[event] then return DT[event](DT, event, ...) end end)
correct: DT.f:RegisterEvent("OnEvent", function(self, event, ...) if DT[event] then return DT[event](DT, event, ...) end end)
Wouldn't "self" be "DT.f" in this case if what I'm understanding is true x:function(x,...)? Thus DT.f would be passed as self when I would need DT? I'm confused on this part.

EDIT: Wait, I see now. I did this before and confused me for days. I see what you're saying now.

Code:
lines 40 and 41
yours: ChatFrame_AddMessageEventFilter("CHAT_MSG_BATTLEGROUND", DT:filter);
correct: ChatFrame_AddMessageEventFilter("CHAT_MSG_BATTLEGROUND", DT.filter);
This was another spot I had concern about. Thanks for clearing it up.

1) Do not try to store all variables in your tables, but only the ones which need to be accessed from other places (or different files). For example, dt.list could as well be just a simple 'local list'.
I'm assuming this references my .toc question, which I'm concluding that you mean keep it simple and just have a seperate "permanent" variable/table for the saves. As far as "list" goes, it actually gets set as table reference via slash command since it's nested in DT. I may be wrong, but not at my comp atm to post the relevent code pertaining to this part.

2) You could eliminate the whole dt.f-variable and the confusion concerning the event-function by just declaring your frame as the addons namespace, e.g. by writing 'DT = DT or CreateFrame("Frame")' on top of the file. Just remember: frames are tables, too
I pondered on this for a bit, but was concerned about miscommunication when using DT as self being passed as a function. I'm still foggy on this, but it makes some sense. Probably click when I can put it to practice.

Last, but not least:
Do not 'enforce' object-oriented programming on all things you come across. Just do it where it makes sense, e.g. defining a global namespace for your important addon functions or passing 'self'. Local variables/functions still have their use and are not excluded by OOP. Just try to find a good balance
Working on it. Just trying to grasp all angles as I go along.
Good luck on your further scripting! OOP makes things a lot more structured and is imho more fun to write.
I've noticed the structured part. In some rewrites, I've also noticed it has the potential of eliminating a lot of hard-to-read code (7+ if/then/else gets hard to sort through).

Thanks for the advice so far, much appreciated.

Last edited by Sythalin : 12-23-09 at 07:25 PM.
  Reply With Quote

WoWInterface » Developer Discussions » Lua/XML Help » Not used to object based yet....

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off