function exists(...)
count = 0
f = {}
for i = 1, #arg do
f[i] = io.open(arg[i], 'r')
if f[i] ~= nil then
io.close(f[i])
count = count + 1
end
end
if count == #arg then
return 1
else
return -1
end
end
Table (array) variables have to be initialized with {curly braces}, and the for / do / end loop is slightly different, but sure...
While you can stack up statements on the same line in Lua, unless it is just one simple statement I tend to break them up and indent so it is easier to follow where the "end" statements fit with the "for" and "if" statements.
The only minor issue I have with this is that if you pass zero parameters, it will return "1" as if it was a success, since count will equal #arg. I think I might test for that...
function exists(...)
count = 0
f = {}
for i = 1, #arg do
f[i] = io.open(arg[i], 'r')
if f[i] ~= nil then
io.close(f[i])
count = count + 1
end
end
if count == #arg then
return 1
else
return -1
end
end
Table (array) variables have to be initialized with {curly braces}, and the for / do / end loop is slightly different, but sure...
While you can stack up statements on the same line in Lua, unless it is just one simple statement I tend to break them up and indent so it is easier to follow where the "end" statements fit with the "for" and "if" statements.
Indeed. I'll keep those Lua particularities in mind, but for now I'm glad I didn't missed the syntax by much.
I'm also for breaking the code into indented "blocks" when there are multiple lines belonging to the same "statement", but I also like turning stuff into "one liners" when possible.
Yincognito wrote: ↑November 17th, 2020, 10:00 pm
Indeed. I'll keep those Lua particularities in mind, but for now I'm glad I didn't missed the syntax by much.
I'm also for breaking the code into indented "blocks" when there are multiple lines belonging to the same "statement", but I also like turning stuff into "one liners" when possible.
Sure. I just find that once the code gets a tad longer overall, it can get easy to miss an "end". It's like futzing with matching up {curly braces} in C.
jsmorley wrote: ↑November 17th, 2020, 9:32 pmThe only minor issue I have with this is that if you pass zero parameters, it will return "1" as if it was a success, since count will equal #arg. I think I might test for that...
if #arg > 0 and count == #arg then
return 1
else
return -1
end
Yep, didn't thought of that, my bad. I guess having this test also depends on what you want the "default" / "nothing" value to be. Normally you'd want it to be "false" (aka -1), but you may very well want that to be "true" (aka 1). That's a good logical question: does nothing exists or it doesn't?
Yincognito wrote: ↑November 17th, 2020, 10:04 pm
Yep, didn't thought of that, my bad. I guess having this test also depends on what you want the "default" / "nothing" value to be. Normally you'd want it to be "false" (aka -1), but you may very well want that to be "true" (aka 1). That's a good logical question: does nothing exists or it doesn't?
Yincognito wrote: ↑November 17th, 2020, 8:29 pm
Ah, very interesting. I was aware of the argument flexibility is most programming languages (like defining two and send only one, e.g. the 2nd being optional), but defining one and send two and Lua being ok with it is new to me. It's interesting, and your example using ... is much appreciated.
To be clear, Lua isn't really ok with just sending more parameters than are defined. That is the role the ... syntax plays. As it might appear, that sorta means "and so on" to a function definition in Lua.
function MyFunction(...)
function MyFunction(argOne, ...)
function MyFunction(argOne, argTwo, ...)
jsmorley wrote: ↑November 17th, 2020, 10:06 pm
I say the cat was dead all the time...
Yeah, me likes cats over dogs, so...
I'll let philosophers answer that one though. Joking aside, your addition was spot on - its' just that I'm not particularly fond of adding exception cases for "in-house" code, although they are a good coding practice in every "book".
jsmorley wrote: ↑November 17th, 2020, 10:14 pmTo be clear, Lua isn't really ok with just sending more parameters than are defined. That is the role the ... syntax plays. As it might appear, that sorta means "and so on" to a function in Lua.
function MyFunction(...)
function MyFunction(argOne, ...)
function MyFunction(argOne, argTwo, ...)