WoWInterface - Not used to object based yet....

WoWInterface (https://www.wowinterface.com/forums/index.php)

- Lua/XML Help (https://www.wowinterface.com/forums/forumdisplay.php?f=16)

- - Not used to object based yet.... (https://www.wowinterface.com/forums/showthread.php?t=29516)

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.

What's the question?

And the question is?

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.

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.

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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.