(this post has been through
hell to reach the forum. After Opera crashed, I was able to salvage it from the depths of memory using gdb. This is why I love Linux.)
Preamble: almost everything here is covered in
2.5.6 Table Constructors and most of the rest in
2.5.7 Function Calls.
Also, some clarification concerning commas:
(1)
The final comma is optional.
This is mentioned in a single sentence in the Manual: "The field list may have an optional trailing separator, as a convenience for machine-generated code." You're allowed to have a comma after the last entry (and this is a good idea, as it makes it easier to insert new entries later), but it's not strictly mandatory.
Code:
-- this is legal
table1 = {
foo = bar,
baz = quux,
zarf = moby,
-- this is too
table2 = {
foo = bar,
baz = quux,
zarf = moby
}
(2)
Commas and semicolons are interchangeable in table declarationsThis is mentioned in the grammar for table declarations:
Quote:
tableconstructor ::= `{' [fieldlist] `}
fieldlist ::= field {fieldsep field} [fieldsep]
field ::= `[' exp `]' exp | Name `=' exp | exp
fieldsep ::= `,' | `;'
Re-using the above example, we can see:
Code:
-- this is legal
table1 = {
foo = bar,
baz = quux,
zarf = moby,
-- this is too
table2 = {
foo = bar;
baz = quux;
zarf = moby;
}
You can also freely mix commas and semicolons in a single table, although you really shouldn't, just for readability reasons.
Personally, I prefer semicolons, but the SupComm coding standard appears to be to use commas.
Recon wrote:
From a programmer's perspective, a lot of this helps, however I'm still trying to get my mind around what certain parts of the syntax are doing.
Like you say AClass = class() {---stuff---}
Ok... what's the point of saying class()
what does that do? How is that different from just saying
AClass = {---stuff---}
This is mentioned in passing in the Manual, but kind of warrants more detail here.
Functions can be called not only as func(args), but also as func{ args }, in which case the function is passed the table in question as its
single argument. Example:
Code:
print( { foo = bar } ) -- call print with a single table as its argument
print { foo = bar } -- same as the above!
What's actually happening in the code you asked about is somewhat cleverer. Class() returns a
function; that function is then immediately called with the { class definition }, and returns the class object itself. That is to say:
Code:
AClass = Class(superclass) { member = value }
-- Class() returns a function, so we now have
AClass = classmaker { member = value }
-- which is a short form for
AClass = classmaker( { member = value } )
-- classmaker returns the actual class, so
AClass = classobject
The classmaker function (which in practice doesn't get a name, but let's call it classmaker for the purposes of this explanation) does extra stuff like setting up the metatable. If you just did AClass = { ...stuff... } all you get is a plain table without any of the extra shinies that give you, for example, inheritance.
Quote:
Also, you mentioned that its assigning a variable to AClass.
What variable?
He phrased that poorly, I think. It's creating a field in AClass (called "AClassFunction"), and assigning a value to it (the function itself).
Quote:
You said AClass is a table, so you can assign variables to tables? How does that work? So instead of AClass being a table, now its a variable? Or is that not the right paradigm?
You can't assign things to values, only to variables. Variables are just names, containers which hold values. (the reality is somewhat more awesome than this, but I figure environment/table equivalence can wait until you have a firmer grasp on the language)
Quote:
When I program, I'm used to this syntax:
Code:
function MyFunction(parameter1,parameter2)
--do stuff
return result
end function
then, in another place I have code which is in another function, but it can call MyFunction, like this
Code:
GetResult = MyFunction(X,Y)
--do stuff with GetResult -- which is a variable..
The above is perfectly valid in Lua.
Quote:
Tables like what Lua has would be represented with something like a collection, which I understand. A table is just a series of inde
xed pieces of information you can access from inside a function.
I am unfamiliar with 'collections'. It most closely resembles an untyped hash table - any value of any type (except nil, anyways) can be use
d as a key, and each key has an associated value (which can also be of any type).
Then it has some additional stuff tacked on (table.key and table:key()) to make it easier to use them as records and as objects. But those a
re just different ways of expressing the same action: looking up a value using its key.
Quote:
But when I look at lua code, I'm having a really hard time drawing the parallels to what I'm familiar with.
I think I understand the part where you declare AFunction.
But when you say AClassFunction = function() I start to lose track of what's going on.
If you aren't familiar with lambda (anonymous) functions, and don't realize that foo{} is a function call in Lua, this can be kind of confusing. Hopefully my explanations above clarified this some; the chapter on function declarations will also go into more detail on what function() means.
Also, in case my frequent mentions of it weren't overt enough, I
cannot emphasize enough that the Manual is the best resource for this. It explains the entire language from top to bottom and is short enough (if you skip chapter 3, which is almost completely irrelevant to SupComm modding anyways) that you can read the entire thing in an afternoon. SupComm has added some extensions, like # for comments, but the manual is still your one stop shop for the lexis, syntax and semantics of the language.
.
