Kingdaro, on 03 December 2013 - 04:02 AM, said:
Wobbo, on 03 December 2013 - 05:09 AM, said:
I would like to just point out to both of you that I know reasons behind their design choices, and I know that some of it is already implementable but the point of me writing this is to see what people WOULD change given the chance, even if it can already be done now.
Kingdaro, on 03 December 2013 - 04:02 AM, said:
The only real case where a ternary condition doesn't work is in this case:
var = condition and false or something_else
Where you wanted to set var to false if the condition was true. However, the easiest way to fix that is to reverse the condition and the "or"
var = not condition and something_else or false
If for some weird reason, the second and third values were false and nil, e.g. "var = condition and false or nil" (this statement would always evaluate to the last value, nil in this case), you're better off using an if statement, which is fine since most people don't really need to do this anyway.
in which case a ternary is just cleaner.
Kingdaro, on 03 December 2013 - 04:02 AM, said:
Personal preference, but I'm fine with checking the type of the value if necessary.
yeh there's just some times where it'd be handy, especially in this case:
theoriginalbit, on 02 December 2013 - 10:05 PM, said:
well for one, having static typing does allow for function overloading, which is one of the major things that I do want in Lua, but can only be achieved through type checking.
Kingdaro, on 03 December 2013 - 04:02 AM, said:
I agree on this one; the whole "value = value or default_value" syntax is pretty verbose and doesn't work if you want false as a default.
Indeed, like I stated, one of the only things about Python that I actually like
Kingdaro, on 03 December 2013 - 04:02 AM, said:
__type and __len (implemented in 5.2) would be very nice to have, yes.
Indeed, I actually just discovered the other day that we actually do have
__metatable, I didn't think we did, actually would have sworn that we didn't have it!
Kingdaro, on 03 December 2013 - 04:02 AM, said:
I actually looked this up a while ago, and there's a specific reason for the assert that works the way it does. A lot of lua functions usually return a value if successful, or nil and then an error otherwise. It makes a neat syntax in a situation like this:
file = assert(io.open('somefile'))
Where assert would error out with the actual error from io.open. Giving a level to assert would erase every other value given from io.open as function params, e.g. the error message.
Ahh of course, makes sense.
Kingdaro, on 03 December 2013 - 04:02 AM, said:
As for what I'd personally like, assignment operators (+=, -=, etc.) since I add numbers to themselves quite a bit, especially when working in games. ++ and -- are definitely redundant though, as it's only one less character to type: "var += 1" vs. "var++".
A part of the reason why they don't implement features like ^that is so Lua remains such a small and speedy language.
Good options to have. implementing those operators wouldn't make the language much larger, and also wouldn't slow it down at all, for example += and -= are functionally no different than expanding, its just less verbose. As for ++ and -- they can definitely help make some statements less verbose.
Wobbo, on 03 December 2013 - 05:09 AM, said:
Of course its possible, I know its possible, but what I mean is this
local function foo(number bar)
print(bar + 1)
end
foo(1) --#> 2
foo("bar") --#> error: expected number, got string
which obviously is implementable, like so
local function foo(bar)
if type(bar) ~= "number" then
error("expected number, got "..type(bar), 2)
end
end
but the point of the former example is its far less verbose!
Wobbo, on 03 December 2013 - 05:09 AM, said:
2. I would like to have this as well, and it can be achieved by creating a function that dynamically calls other functions. The wrapper function would have a closure with defaults and the order of the arguments, and it would call the function accordingly. Not really what you are looking for, but it is better than nothing.
-code snip-
yeh I've made a similar script in the past that dealt with type checking and defaults, so the signature was
parseArgs(args, argTypes, argDefaults)
and each table was an indexed table for it to work
Edited by theoriginalbit, 03 December 2013 - 06:07 AM.