[Sythalin]

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).

lines 19 and 33
yours: local DT.f = CreateFrame("FRAME")
correct: DT.f = CreateFrame("FRAME")

Thanks, woulda missed that.

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.

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.