Thread Tools Display Modes
11-28-05, 07:24 PM   #21
Rowne
A Fallenroot Satyr
 
Rowne's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2005
Posts: 26
Indeed, to each their own. I'm sure there is a place for locals if there are vital functions andsoforth that you wish to keep safe. I like being able to hijack though. In fact, I believe that as we're all learning more about Lua (well, most people know more than me ... so perhaps it's just that I have a lot to learn), it occurs to me that this might be one of the next steps in the evolution of dynamic code. In fact, we could avoid a lot of the problems created by resource usage by re-using things, I'm already getting into reusing variables as much as possible, thusly making my variables generic so that the GC has less to deal with. On that line of thinking though, it occurs to me that one day we might be doing that with functions too, swapping functions in and out of a couple of active generic functions. It's an idea that I'm curious about, to be sure.
__________________
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
11-29-05, 12:31 AM   #22
Silversage
A Flamescale Wyrmkin
AddOn Author - Click to view addons
Join Date: Nov 2005
Posts: 132
Rowne, I'm in complete agreement.

For my own code, I prefer, stylistically, to use colon-syntax just so that involves less thinking and remembering on my part. About the only time I don't is when a procedure has to be replace an API procedure, or be passed as an argument to something in the Lua standard library (e.g., table.foreach or string.gfind).

Over the years, I've worked in a variety of languages. Among scripting languages, Lua is a hands-down winner for getting the most mileage out of a few simple constructs.
  Reply With Quote
11-29-05, 02:17 AM   #23
mondinga
A Theradrim Guardian
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 66
Didn't read quite the entire thread, but wanted to drop a comment on the general practice.

I've been using it quite a lot for a while now. All GypsyMod code starting with the releases I'll be making when 1.9 hits will branch off of a central object ('Gypsy' of course!). I've developed a central code base that allows me to maintain full standalone capabilities for all add-ons, but which also expands on their interoperability greatly. Through a very thorough load sequencing and version checking practice, and utilizing file local variables and functions as much as possible, it is both efficient and pleasant to work with. I've also got a few function libraries I include with different add-ons, and some classes for doing stuff like localization, which get inherited by whatever objects need them. OO is where these things excel.

On the topic of local and object functions, I tend to save locals for large blocks of specialized/specific code - contents of a drop-down menu for example - some occasional hooking, and when I need to pass a quick function through somewhere - drop-down menus a good example again. A local function is generally doing one thing, and if that needs to be changed, the function that is actually utilizing it can be hooked.

On colon vs period syntax. Plenty of my functions utilize self, and some don't, but so far for ease of recognition and future code changes I've kept all functions accepting self as the first argument, and all function calls using the colon, with a few necesary exceptions. I can see the argument that it isn't necesary, but in my setup it's quite helpful. Any given level in my object tree can contain keys of any type of value, so it really helps make function call syntax distinct.

Anyway, I really enjoy OO, and in the fairly extensive usage I've given it, I haven't noted any performance changes. If anyone is interested in seeing what I've done and am working on, let me know on IRC - I'd really like some feedback.
  Reply With Quote
11-29-05, 02:23 AM   #24
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
My casual unit tests of a global function within a table, a normal global function and a local function (all did just local i=1) showed 0.024 sec, 0.020 sec, 0.018 sec respectively for 100k calls.
  Reply With Quote
11-29-05, 02:35 AM   #25
Rowne
A Fallenroot Satyr
 
Rowne's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2005
Posts: 26
Qzot and Mondinga Thanks for the thoughts, it's really nice to have a couple of big names in here, offering their opinion. My first concerns really are the player and the community and what's better* for each. What'll impact each less and what'll unlock the potential more for both. I really have given this a lot of thought. Hopefully this thread will present a good option, not to say that folks should use OO but to show the benefits if they did choose to do so. All I set out to do from the start was to raise awareness, that's all, nothing more and I'm sure that your words will no doubt help with that.

Gello Yep, so there is a slight overhead but it's really infintessimal. Especially when combined with the gains spoken of above, that we won't pollute the namespace and that we're not holding back on the community potential of our works. Thanks for that Gello, I appreciate you posting those times up here because it gives people a clear view now of all the pros and cons. It's always good to balance the views.

--- Edit ---

* When I say better here, I don't mean better as in the best or Right/only way to do things but more succinctly and correctly, the way that won't blow up. As I stressed in my first post, the namespace can be a warzone for variables and functions if not used correctly and it can get polluted and messy. I think it's only right that we should behave in our environment, whatever that environment happens to be. Good behaviour seems to be the better behaviour and that's all I intended to say there.

Sorry to overextrapulate but I just want to show my goodwill here and that I really mean no harm with the opinions I offer.
__________________
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?

Last edited by Rowne : 11-29-05 at 02:45 AM.
  Reply With Quote
11-29-05, 09:59 AM   #26
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
in a perfect world Blizz would segment addon and game code anyway. You would then be requierd to access addons via addon.YourVariable, while blizz created code would show up in its own global namespace such as global.BlizzVariable

I know that might seem extreme, but it would add a little bit more security and protection against overlapping namespaces, not to mention go further into making all code OO based. There are many possibilities for what Blizz could do to further the OO initiative, but anything they do now would be a radical change from what we have now...

For now I just do my part by making all my code OO based. I personally would love to see addon developers take the initiative to do the same. In the end there can only be benefits. In the extreme I would love to see all code become modular as described above, by separating addons and blizzard default code into separate namespaces. But as wel all know, OO is more an ideal and coding habit / standard than it is a requirement. Not everyone will embrace it like some of us have...

Last edited by Beladona : 11-29-05 at 10:07 AM.
  Reply With Quote
11-29-05, 10:17 AM   #27
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
If the global lookups are so fast (which they appear to be. The difference between local and global is very small), then doesn't that mean the only downside to polluting the namespace is collisions? Which is a big deal and in itself makes tables worthwhile. But I'm trying to see the real benefit before I try a mod with an OOP slant.

Other than collisions, what's the downside to polluting the global namespace?
  Reply With Quote
11-29-05, 12:35 PM   #28
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
I can only think of collisions right now as being the main if not only downside. There are several upsides however.

I know at least a few of us here understand OOP and how it applies to LUA, but I found this article that does a pretty darn good job of explaining it in semi-laymans terms. It isn't LUA related, but it can still be applied...

http://www.debreuil.com/docs/ch01_Intro.htm

I am thinking about taking that article and creating one similar but oriented towards LUA specifically...

Last edited by Beladona : 11-29-05 at 12:39 PM.
  Reply With Quote
11-29-05, 04:09 PM   #29
Rowne
A Fallenroot Satyr
 
Rowne's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2005
Posts: 26
It's not only collisions but it's actual pollution that can't be good for the namespace, for exampe -- how do you support saving your variables? The point I would like to make is that flat-global functions are the same as using RegisterForSave(variable) and flat variables.

I used to remember when AddOns did that and in our SavedVariables we'd have this horrible mess, like ...

["MyAddOn_Var1"] = val
["MyAddOn_Var2"] = val
["MyAddOn_Var3"] = val
... and so on ...
["MyAddOn_Var16"] = val
["MyAddOn_Var17"] = val
["MyAddOn_Var18"] = val

Then right below it there would be an entry that is instead ...

Code:
["AnotherAddOn"] = {
   ["Var1"] = val,
   ["Var2"] = val,
   ...
   ["Var18"] = val
}
The principle is the same here, almost everyone switched to tabled SavedVariables because of the awful mess we were creating in their SavedVariables, however, by using flat global functions/variables, we're making the same kind of mess in their memory-space and that can't be good. I'm sure there's a million coding reasons why we should avoid making memory-area messes like that, I'll look it up and try and find a good few valid ones.

Realistically though an AddOn is 'flooding' the namespace when it doesn't need to be. An AddOn coded in OO will only leave one footprint in the namespace, whereas an AddOn coded in flat globals might leave anything up to 100 footprints, or more. This makes the namespace hell to traverse, I'm sure.

In fact, if you do a search on namespace pollution via Google, you'll find that every site that talks about it says that it's a bad thing and that we should avoid dropping loads of global footprints there for one piece of code. Even Programming in Lua, the official book on Lua programming, advises that we not do it.

The only reason I could imagine that everyone would be so steadfastly against pollution is that by polluting the namespace, it'll lead to detrimental effects on the Lua environment. What those are exactly I'd have to research but I wouldn't want to force the issue by finding out through experience.

Summarizing: There's nothing to say that you must use OO but not using OO or at least a tidy tabled system is like leaving hundreds of pairs of unmatched socks and pairs of underwear lying around your bedroom. It has the obviously detrimental aspect of global collision but for it to be unadvisable in such a widespread way (as it is), there has to be more to it than that. Can anyone dig up some resources on this for us?
__________________
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
11-29-05, 05:44 PM   #30
Kasheen
A Wyrmkin Dreamwalker
 
Kasheen's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2005
Posts: 58
Personally I prefer OOP when it comes to coding anything, however I seem to write my mods in procedural. I have been meaning to pickup OOP in LUA and port my mods but haven't had the time since I had to drop wow.

Anyway, enough about me and onto a point. While I guess that most people who are writing mods will have some sort of programming background, some may not and hence not understand OOP. Perhaps that is why some people opt for procedural?

Edit: Its a good topic by the way, its nice to see something like this.
  Reply With Quote
11-29-05, 07:45 PM   #31
Rowne
A Fallenroot Satyr
 
Rowne's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2005
Posts: 26
Mmhm, that's exactly why this thread exists. I set out to let people know that there are other ways of coding. One problem with having FrameXML as a resource that I see is that Blizzard sets a bad example by coding in procedural themselves. I could never understand why they did that but it's their game so they can code however they like. However, just because Blizzard does something, it doesn't mean that we, as the community, should follow that example.

This is a drive for OO awareness really and I've been tempted to try and put something together on OO, with a few basic OO AddOns, both Ace and not just to show people the difference between OO and procedural. To put it bluntly, I've been tempted to write a 'thesis' of sorts on the topic so that folks will have a centralized resource base on how they might get into OO, not just for coding or for Lua but specifically in regards to making AddOns for World of Warcraft.

This thread was basically my wondering whether it was simply that OO was unknown (which seems to be the case) or whether OO was considered to be some black sheep for whatever reason. Since it seems that folks might be interested however, I think I'll put together that thesis anyway and if anyone wants to chip in with resources, examples and so on, then please do.
__________________
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
11-29-05, 09:31 PM   #32
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
I think the main issue, as Kasheen pointed out, is that most people are just trying to get a handle on LUA. OOP just seems like something beyond their ability to learn.

From my standpoint however, it is easier to learn OOP from scratch when learning LUA, than it is to make the switch from procedural to OOP after you have been doing procedural for a long time...
  Reply With Quote
11-29-05, 10:18 PM   #33
Esamynn
Featured Artist
Premium Member
Featured
Join Date: Jan 2005
Posts: 395
Originally Posted by Rowne
In fact, if you do a search on namespace pollution via Google, you'll find that every site that talks about it says that it's a bad thing and that we should avoid dropping loads of global footprints there for one piece of code. Even Programming in Lua, the official book on Lua programming, advises that we not do it.

The only reason I could imagine that everyone would be so steadfastly against pollution is that by polluting the namespace, it'll lead to detrimental effects on the Lua environment. What those are exactly I'd have to research but I wouldn't want to force the issue by finding out through experience.
I would be interested to find out if pollution of the global namespace has any downsides other than the potential for collisions. I have always used the underscore character in my global function, variable and frame names to simulate OOP in spirit, and I have been unable to ponder out any reason as why this is not just as good as true Lua OOP.
  Reply With Quote
11-30-05, 03:55 AM   #34
Kasheen
A Wyrmkin Dreamwalker
 
Kasheen's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2005
Posts: 58
Originally Posted by Beladona
I think the main issue, as Kasheen pointed out, is that most people are just trying to get a handle on LUA. OOP just seems like something beyond their ability to learn.

From my standpoint however, it is easier to learn OOP from scratch when learning LUA, than it is to make the switch from procedural to OOP after you have been doing procedural for a long time...
Definately agreed. My first main programming language a while ago was VB6 and I had quite a time going from that into C# and Java purely because I was so used to the ways of vb. But once you get the hang of OO it is very very easy and extremely powerful in comparison. VB6 wasnt exactly real procedural though, it was sort of an OO hybrid.

Edit: Mind you I'm guessing "Objects" in lua are still dynamically typed as its more of a scripting language so prolly wouldn't be as hard as getting to learn C# or Java or the likes. I guess it will have other quirks to reduce some of the programming overheads of a real OO as well, like a scripting language should. . . .

Perhaps some example mods would help people understand and see the differences between the two, and then they may think "hhmm thats not so bad after all"!

Last edited by Kasheen : 11-30-05 at 03:59 AM.
  Reply With Quote
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
11-30-05, 11:15 AM   #36
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
I think the primary advantage of an OO style is organization. I'm working on a new small mod I'll try this method as an exercise. It didn't take long to understand the syntax. Unfortunately it seems to have limited application to the xml. One of my most recent mods has less than 100 global names created in the lua "side", but over 200 global names created on the xml "side":

<Button name="MyButtonTemplate" virtual="true">
<Layers><Layer level="ARTWORK">
<Texture name="$parentIcon"/>
<FontString name="$parentName"/>
<FontString name="$parentData"/>
</Layer></Layers>
</Button>
<Button name="MyButton1" inherits="MyButtonTemplate"/>
<Button name="MyButton2" inherits="MyButtonTemplate"/>
<Button name="MyButton3" inherits="MyButtonTemplate"/>

The above creates 12-13 global names. When dealing with scrollbars and stuff it adds up fast. Ironically the above seems to be OO in concept but it doesn't help the namespace at all.
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.
hehe I read that as an argument against OOP. Replace "folder" with "table." I'm not against OO at all and like the idea, nor do I feel that there is a "crusade" to make everyone do stuff in one way. But just to play devil's advocate to learn more: What is resource? Is it performance (clock cycles), memory space, the stack?

Allocated memory for tables grow semi-exponentially in lua. It can be argued that a more "flat" namespace will exist more compactly in memory. Think of how many M&Ms you can put in a jar with and without the wrapper. Strings and tables exist as references within the table, but the shocking table growths I saw in Recap showed a serious footprint growth to complex tables. Moving a table of 100 combatants with full details (too much detail heh) would go from 1mb to 50k by collapsing it from a complex table to a "flat" table of strings. (edit: to be fair the flat tables were compressed somewhat but the difference floored me)

While it's obvious that local lookups are faster than global which are slightly faster than global table lookups, I'm inclined to believe that less stuff in the global namespace may eventually help performance because as the global namespace gets really large then the first lookup will exceed table lookup. But where that "really large" threshhold happens I'm unsure of, or if it's practically achievable with mods. Is there a way to scan the global namespace to see how many global names there are? That would be an interesting study: to determine how many names in the namespace (including blizzard's default UI) it would take before it takes longer to do a global lookup than it takes to do a table lookup with the default UI and one non-default global name.

I liken the WoW UI sandbox to the old DOS/Win3.x days with the 640k memory limit. For large projects there are definite advantages to organization that's worth a little overhead. And of course I'm sure the ease of doing things sloppily in a non-OO way eat up the performance/memory gains. Personally I think the liberal use of localization files that add hundreds of globals is a greater crime than doing mods the same way blizzard does but that's another topic. :p

Last edited by Gello : 11-30-05 at 11:26 AM.
  Reply With Quote
11-30-05, 11:21 AM   #37
Beladona
A Molten Giant
 
Beladona's Avatar
AddOn Author - Click to view addons
Join Date: Mar 2005
Posts: 539
agreed. Whenever someone asks me for my thoughts, input, or assistance on a script, I always do it with OOP in mind. I would be willing to help anyone with figuring it out that needs it.

Maybe I need to register on the ace forums, as it sounds like there are a lot of OOP discussion going already...
  Reply With Quote
11-30-05, 11:33 AM   #38
Gello
A Molten Giant
AddOn Author - Click to view addons
Join Date: Jan 2005
Posts: 521
Now I'm even more interested in the resource bit. I tried without success months ago to determine how much memory a table takes up. But I think this can be approximated by making hundreds of copies and then doing a reload.

Is there any way to get a list of all global names for the performance test? With MyMod_UnitFrame_Party1_HealthStatusBar_GaugeTexture, doing a getglobal("a") getglobal("aa") etc would take years to run.
  Reply With Quote
11-30-05, 11:52 AM   #39
Esamynn
Featured Artist
Premium Member
Featured
Join Date: Jan 2005
Posts: 395
An interesting comparison would be the difference in performance between a table lookup and getglobal. I would do it myself, but I can't get at the game at the moment.
  Reply With Quote
11-30-05, 12:18 PM   #40
Rowne
A Fallenroot Satyr
 
Rowne's Avatar
AddOn Author - Click to view addons
Join Date: Sep 2005
Posts: 26
Gello Actually, I'd think it would be a bit different because the tables are processed on a different level to the namespace.

On loadup, for example, one namespace entry would be one thing to process. The rest would be executed by the parser in game.

However, with procedural, we'd be going bumpity-bumpity-bumpity along all those procedural names, processing the namespace before even getting into game. In fact, I'm partly convinced that login lag is caused by procedural pollution because users have reported that by switching from other AddOns to Ace(D) variants, they've seen incredible speedups in login times. In fact, this is one of the reasons I started pimping OO with fervour.

This isn't just about Ace for me but the fact that as far as I can tell, from all that I've heard users say, procedural is genuinely detrimental. I'm sure it's one of the reasons why Ace sees such incredible leaps in speed versus other systems out there right now.

This isn't to promote Ace because allow me to point out, all Ace AddOns are OO by default, so I'm considering this from an OO standpoint. If we're seeing great speed increases and the structure of the code really isn't that different then part of that increase must be to do with how we're actually doing the coding.

I wouldn't mind betting that a small part of those increases are down to OO. As I've said in the past, the official Lua programming book, Programming in Lua, states that procedural is a bad way of going about things and in no uncertain terms states that those who code in Lua should use OO, you can check out the book to see that for yourself.

I took all these factors into mind before I started posting here. So I gather that any results will only back up what I've said because the conclusion I'm trying to draw (even if it is a bit false) is that Lua seems to be designed to work in a more optimized way if coded in OO than if it's coded in procedural because every official Lua source I've encountered (including folks from ##lua on irc.freenode.net) would say that OO is the only proper way to do it.

So I'd like to see these tests done too because all these people can't just be piping up OO on a whimsical desire.

The thing is, I feel like the Warcraft community is getting left behind the rest of the World and doing things that primarily could be detrimental to Lua whilst those who've been using Lua long-time already know this. This is why I'm going to try and poke a particular Lua-nut I know of to stop by here and give us the exact lowdown. If anyone would know, he would.

I think my point is that it isn't so hard to imagine that Lua would be optimized to work with OO better than procedural and it's simply Blizzard that got it wrong, as opposed to Programming in Lua and the experts. I won't just leave it at my word though, as I said, I invite you to look around and I will poke the nut I know to see if he'll add a few words here because I'm sure that my suspicions have to have some kind of solid ground.

Belladonna Yup, all Ace AddOns since the inception of Ace have been OO. It was actually the foundation of Ace. The very reason I hopped on the Ace bandwagon was because at the time, I didn't know about OO in Lua and the procedural way of coding was driving me nuts. It was (from my point of view about my own code, originally) ugly, messy and just plain wrong. I felt like a litterer with every AddOn I released. Professionally it just wasn't a good way to code AddOns. Then Turan came along with Ace and said "Look at what I've made." Suddenly it clicked. Not only could I use OO in Lua but now I also had a framework. What it reminds me of to be honest (Ace that is) are the 'framework stubs' you can get for the Lua parser and for other environments.

I'd welcome your thoughts over on the wowace.com forums too because we're always looking for ways to optimize, we're all optimization nuts. If Blizzard gives us a new function, we jump on it like feral beasts who've not been fed for weeks (no, really, you should see us sometimes). There are folks who're constantly trying to improve the way things are run so if you see something that you don't think is efficient or if you know of a way to improve the way we use OO then please tell us because ... as I said, I'm very easily influenced by a good argument if it will result in cleaner code and a cleaner environment. S'why my code is almost bloody polymorphic in its very nature. Ever changing. So I'd like to hear what you've got to say. Ace always has its doors open to those who really want to show us better ways to make a moer efficient AddOn.

--- Edit ---

Another interesting point to make would be cumulative results, which could explain a lot. Sure, we've tested one function versus another one function but I don't think we're going to get real results until we compare 30 functions in one OO-object/table versus 30 procedural functions because what I'm thinking is that each time we create a procedural stamp, we're creating a base amount of 'baggage' for that stamp. Whilst one procedural might have less baggage than one table. 30 procedurals however might have far, far more baggage, being individual, than 30 tabled entries. I think these are the kinds of tests we need to run as they'd also explain the results the Ace community has seen.

Furthermore, it wouldn't be fair to count the table in each test either, the table should only be counted once because it only gets processed into a pointer once by Lua. A table isn't recreated every time it's called, it's only created on login or at the time of GC. So if we were to run a test, we'd only be able to consider the table element once and each function once. So we couldn't do table x 30 + tabled function x 30 because that's not how Lua porcesses. It'd be table x 1 + tabled function x 30. This is what I was trying to get at in the previous paragraph. Because I think it's stamp x 1 versus stamp x 30 and that's where the problem arises.

--- Further Speculation ---

I dare say that in fact, this would be much like how we'd consider a program. There's a reason programs like say, the GIMP, Miranda and so on have plugins. What would happen if we created a program and then made all of its plugins programs instead? All of the baggage that comes with a program versus a plugin would count for each program. So instead of 1 x program and 30 x plugins, we'd have 30 x programs and the baggage that each new instance of a program in memory would bring. So we'd actually be considering how the baggage of each individual entry would work versus a program with plugins. Certainly, if a program is going to be able to support plugins, it's going to have a slightly bigger stamp than a program that doesn't support plugins, but I find that if you load a program with 30 plugins instead of 30 programs, the memory stamp is much smaller.

This is the point I was trying to make above, that because we're not actually linking the footprints to one central point (a table), every new procedural function or global variable is a completely new instance and that instance has all the baggage that a new instance in the Lua environment that a new instance carries. Whereas in a table I strongly suspect that that baggage is lessened because it's shared by the table. Lua recognizes the table as a single instance and that the functions and variables that lie within aren't. So a tabled AddOn therefore is more like a program with plugins as opposed to lots of different programs.

--- Erm ... something more to add. ---

I want to apologize if I'm flooding you all, I'm a very 'thinky' person and I can speculate easily, that's why I want to see these tests run to see if my suspicions are right but I digress. I process things pretty quickly and I can tend to yammer on and on and on about things, it can be overwhelming. If I'm annoying anyone by going on and on about things too much, feel free to tell me to shut up for a bit or to make smaller posts, I won't take offense. ;p I know I can be gabby and I know it can be annoying even though I don't intend that. So ... I just wanted to say that. Now, back to our regularly scheduled OO discussion.
__________________
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?

Last edited by Rowne : 11-30-05 at 12:41 PM.
  Reply With Quote

WoWInterface » Developer Discussions » General Authoring Discussion » OO initiative.

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