OO initiative.

[Rowne]

Allow me to get two things out of the way; 1) this has nothing to do with Ace, 2) I'm not trying to stir up trouble.

I've been wondering lately with the advent of object-oriented programming as described in [Programming in Lua], why more authors haven't switched to object-oriented code, I gather it's mostly because of the lack of awareness of it (at a guess). Blizzard uses non-OO code themselves, which I would surmise that most people use as a base to create their own AddOns from.

The reason I promote OO is because unlike the usual script based system of coding, OO doesn't leave names lying around in the global namespace. Here's an example ...

function MyAddOn_SomeFunc()
   Some_Var = value
end

function MyAddOn_SomeOtherFunc()
   Another_Var = value
end

function MyAddOn_AnotherFunc()
   Yet_Another_Var = value
end

In the global namespace you'd then have ...

MyAddOn_SomeFunc
MyAddOn_SomeOtherFunc
MyAddOn_AnotherFunc
Some_Var
Another_Var
Yet_Another_Var

Now here's the OO approach ...

MyAddOn = {
   someVar = value,
   anotherVar = value,
   yetAnotherVar = value
}

function MyAddOn:SomeFunc()
   self.someVar = value
end

function MyAddOn:SomeOtherFunc()
   self.anotherVar = value
end

function MyAddOn:AnotherFunc()
   self.yetAnotherVar = value
end

This would leave only MyAddOn in the global namespace and nothing more. In fact, if you put your constants in a MyAddOn.Const table and your main AddOn in a MyAddOn.Obj table (take a look at ZooKeeper on wowace.com to see what I mean -- I'll get those uploaded here soon) then you only have MyAddOn in the global namespace, period.

In fact, a while back, Eraphine was designing an AddOn and he had a var with something like ElapsedTime in it. His AddOn wasn't working. I told him that it was because it was a constant, it was no doubt being snatched up by another AddOn which was also using it as a constant inthe namespace and nil'd. He was, of course, a bit doubting of this; "Nah, that can't be right." He tried it though and lo and behold, that's what it was.

On changing the variable to self.ElapsedTime, everything worked dandy.

This is why I'm hoping I can get more authors to switch to OO -- because it's less pollution within the name-space, it's better all in all and it'll mean less collision between AddOns. Now some people have took it that I'm an elitist in regards to Ace, that's not true. It's simply a misunderstanding based on an assumption. I've said that Ace is a really good system and that I'm not so sure about non-Ace AddOns.

Why is this?

It's because most non-Ace AddOns still use flat-function/flat-variable system, those are prone to, as I said, polluting the namespace and collision. It's nothing to do with that I think 'Ace is the better dependency'. That's just been assumed. It's to do with the fact that in the Ace community, we're all using OO. You don't have to use Ace to use OO. So allow me to stress that right now.

I tried really, really hard to present this without being obnoxious, I honestly did. If I came off wrong, feel free to yell at me because I probably deserve it but I'm just trying to convey a view here. I don't mean any harm by it. Really.

The reason I'll often look at a non-Ace(D) AddOn and then decide not to use it is because it isn't OO. If it was OO or at the very least, tabled then I'd snap it up and give it a look. I think the problem with flooding the global namespace (like Blizzard admittedly does) is something of a problem that coders might want to look into.

Don't take this as a "You should work this way!", it isn't. It's just a "Hey, here's a different possibility, check it out and see if you like it?"

So ... yanno, my thoughts, take 'em or leave 'em but I thought I'd share.

[Cairenn]

Sharing in a non-inflammatory manner is a good thing. That's why these forums are here and why the #wowi-lounge irc channel exists. Neutral territory for coders following various schools to come together to *discuss* ways in which to accomplish things. Thanks for posting this Rowne.

[Beladona]

good post Rowne. I tried to bring this up months ago, but it kind of died out. This is exactly how I code. Minimizes the "surface" space of your addon in the main namespace, making coding a lot easier to read, use, and also makes your variables less likely to overlap one someone else made...

[AnduinLothar]

We've been doing OO in a similar way in Cosmos libraries since beta. Example:

MyAddOn = {};

MyAddOn.SomeFunc = function()
   
end

MyAddOn.SomeOtherFunc = function()

end

MyAddOn.AnotherFunc = function()

end

The only real difference is that it doesn't pass the MyAddOn table as the first argument and that you call it using '.' and not ':' Ex: MyAddOn.AnotherFunc()

In some cases having the self passed may be useful, say for abstracting frame code, but for most code I've seen it's not used. What are some isntances in which it might be good to have?

Also I'd have to say the method of OO that you listed confused the heck out of me when I first read similar code, but I think the example I gave is a little easier to understand at first glance. It's less complex.

[sacha]

Great thread - Im learning something today
BTW - Is there any advantage/disadvantage to using an approach as below?

local function somePrivateFunction()

end

local function somePrivateFunction2()

end

MyAddon = {

  somePublicVariable = value,
  somePublicVariable2 = value

};

MyAddon.somePublicFunction = function()
  -- may use a local function in here, or not
end


MyAddon.somePublicFunction2 = function()
  -- may use a local function in here, or not
end

Also I am not sure whats the significance of using "function MyAddOn:AnotherFunc()" as opposed to "MyAddon.somePublicFunction2 = function()" , I will read the lua docs again, but if anyone can explain it to me in simple terms Id appreciate it

[tardmrr]

The colon versus the dot notation is what they like to call "syantactic sugar." It's short hand for passing the table as the first argument.

All these are the same:

function Table.func(self,...)

end

Table.func(Table,...)
Table:func(...)

function Table:func(...)

end

Table.func(Table,...)
Table:func(...)