Lua files and objects
 

Hello

I'm a programmer with a couple of years C# and JavaScript experience and I'm wondering how to perceive the lua environment in an object oriented context, in ESO.
I'm talking about classes, objects and locals.

I can't get my head around this: a local function in a lua file, is local in that file and can not be used in another file. Does this mean every file is an object by itself? A function maybe? What about my lua files where I define a class? Those locals are, I hope, local for an instance of that class?

Once I thought all lua files are just a big, sequential script, where you can create objects/function/constructors like you would do in javascript, but then again, the locals, why are they still "local" then.

Hopefully, my queston is clear: I can't seem to relate or project this lua environment on my C# or javascript experiences.

Any help or point of view would be appreciated :)

My first stab at a "Test Addon" to aid development shows a bit with the various variables and their definitions (global, local, function local, etc..)

http://www.esoui.com/downloads/info2...AddonTest.html

Might give you a better idea of how it works if you look at the code while using it in game.

Thanks for the goodwill, but I did not mean that. :(
As I said, I'm a professional programmer, so I do know what "nil" means and what the difference between a class and an object is.
I was asking someone to explain the OO landscape in the context of this game and lua files.

Not at all, because LUA in itself is not object oriented.

What is done is that objects are mimicked, very much like you can do this in ANSI C.

You can't have an object with methods in ANSI C, but you can have a structure with function pointers.
You can't have an object with methods in LUA, but you can have a table with variables and functions are valid variable contents already in LUA. The rest is how to name and group tables and variables consistently, to make it feel like object orientation.

Okay, one trick is there that is...when you have a table and you want to lookup the content of table (a.ka. call a method of the object) you can rewrite the object instance to also look somewhere else for a table entry and if this somewhere else is the Singleton table, which you used as template to create a new table from, it feels like inheritance, because the function of the "master table" is called, if your instance didn't implement it.

So yes, it is a big sequential script. Of course, in ESO it's also a big loop and state machine, so it doesn't feel that sequential. That variables have a scope does not make it less sequential. And as LUA defines every variable as global by default, you have local to limit the scope. Unlike JavaScript, where a var inside a function is already under local scope. In LUA it is global.

I think a good place for you to start reading is how Lua's scope works.

You should read something more in-depth, but here's a quick and dirty explanation.
Lexical scope; "local" variables are local to the block in which they're defined. If they're not defined as local, they are global. Local variables are local to anything in the block in which their defined, including all nested blocks.
Declaring local outside of a block in a file makes that variable local to the whole file. A file can be thought of as a block of code.
Files are not classes, nor can they really be considered objects. They're scripts. Blocks of code. With the script you can define classes and semantics for creating objects.

For some examples about how objects work (in the ESO add-on world, specifically), check out "LootDrop" or "Advanced Filters". You can also look up "Lua classes". It requires some trickery with things called metatables to simulate OO.

Re-reading all that, I dunno how well I did at explaining anything...

No problem. :)

The addon does show the difference between local/global and how it relates to ESOUI and .lua files however.

If you are new to lua I suggest you to read Programming in Lua. This is an old edition but the fundamental concepts are still valid. There is a chapter about object-oriented programming (16). I think it's better to read the book than to sit on broken code and wonder why it isn't working the way you expect it to work (because you know other launguages and think it should work the same way).

Thank you all. Very helpful