Thread: OO initiative.
View Single Post
11-30-05, 09:46 AM   #35
Rowne
A Fallenroot Satyr
 
Rowne's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2005
Posts: 26
Kasheen and Belladonna Whilst I understand that to an extent, I don't think we should count people out. Over on the Ace forums, we had folks who were just bystanders and users for a while and those who'd knocked out a few AddOns via procedural already. The nifty thing with Ace though is that we have a decent knowledge base already, lots of us have created simple AddOns and some exist primarily to demonstrate how Ace and OO work (take a look at Touchdown in the Classroom forum). In fact, there was even a few classes held which seemed to work for some people. Others reading those files got a handle on things pretty quickly.

Lua isn't that complicated a language and really, Lua is good with OO even, if one were to grab a Lua parser and start fooling around, Lua is self-teaching because the parser would find any issues with the current code and then offer solutions. In fact, this is how I learned Lua and my code really evolves not just by the day ... but by the hour. Every optimization I find gets into my regular coding, no two AddOns of mine are coded in exactly the same way, I'm always picking up new tricks and I still think I have a lot to learn and there's no time like the present to start learning. I think Lua is easy to get into with either procedural or OO, it's also easy to switch from or to either. It's just hard to master Lua.

Though nobody expects anyone to do that.

I guess my point is that since we've seen such incredible results using Ace as a launching base for OO awareness, I don't think it's that OO is difficult in any way, it isn't. In fact I don't think anyone would have any problems converting any of their AddOns right now. It's just that people don't know OO and people are afraid of what they don't know because it might be difficult to learn. Take it from me though, it isn't. This is why my opinion is that we should start building resources and example AddOns to demonstrate how OO works. I'm sure that if we did we'd catch the attention of a lot of coders. Just like Ace did. Not everyone's going to use Ace because it's not everyone's cup of tea. That's fine. If we can get people working on OO though, it'll help promote code cleanliness as a global ideal at the very least.

That's just my opinion on the matter, of course.

jbcc Well, as I've gone over before, using procedural is like having a room's floor covered in dirty, mismatched socks. Not only can it make collisions possible but it makes traversal hell, both for the client and for any AddOns that wish to traverse the namespace. In fact, I'm sure this must have a resource hit somewhere because everything needs to traverse the namespace and it's like the directory of a hard-drive. On a hard-drive, if you keep things in one folder only, if you kept all your files there, the hard-drive is faster and defragments less quickly. However, as your file structure gets infinitely more complexe and strews about, your hard-drive becomes far more quickly fragmented.

I'm sure that the mess that procedural AddOns can leave in the namespace can do similar things to the Warcraft client because that leaves hundreds or maybe even thousands (depending on what the user is using) of stamps in the namespace when realistically, those stamps shouldn't even amount to more than one per AddOn that the user is using.

Let's consider that your AddOn has eight global variables and 30 global functions. Now that means that you have 38 global stamps in the namespace. Versus my one stamp. I'd have ZooKeeper and that's that, you'd have AddOn_*1, *2, *3, ... and so on. That can't be good. I need to find some solid reasons why but as I said, I'm sure the strewn nature of it is bound to have a detrimental effect, just as it does with any file system.

In the end, it also becomes harder for anything to group something as 'your AddOn'. For example, if an AddOn was to traverse the namespace to look for all the functions in memory, a good AddOn would have all of its functions related directly to itself. So the namespace would only have one entry and traversing the table of that entry would result in all the functions of that AddOn which could then be linked to that AddOn. However, with procedural that AddOn would have say ... hundreds of "Dunno where this came from." entries. This would mean that if an AddOn is OO or at least tabled, it's easier to monitor the AddOn, for resource monitoring systems it's easier to gather information about the AddOns and all of their innards loading.

I guess what I'm saying is that traversal and interAddOn grouping becomes next to impossible to ID if the AddOns are procedural.

Anyway, I'll do osme more research on this and ask around. I also know a couple of coders who're really in the know who might have something genuinely interesting to say on this.
__________________
There can only be so many ways of doing things; rope rubs against rope and it causes fire, fire cleanses all. Sadly, the ropes can't be around to appreciate it.

Short: Tolerance FTW?
  Reply With Quote