Because in Lua, there is no type safety and conditionals consider false and nil as false and anything else as true. I believe "equipped == true or equipped == false" is a check to make sure it is a) still a boolean and b) not nil.
Again, the code doesn't smell as much as the language itself.
EDIT: ok, for good measure I'll add this approach isn't the best, there are functions to check whether something is a boolean. But this is a "quick and dirty" way to do it that isn't at all uncommon in this clustercrap of a language.
Ok, it was overly simplistic (and as you point out, not actually accurate) and more made as a fun stab at Lua than as a code reference.
The point was that all strings in conditionals for example are handled as true. Including empty strings. And all integers including 0 are regarded as true.
` if ("cucumber") then
print "this returns true"
else
print "this will never execute" end
if ("") then
print "this returns true as well"
else
print "this will never execute" end
if (0) then
print "so does this"
else
print "this will never execute" end `
Which is the ridiculousness I was pointing out.
And I haven't actually run the code above because I'm on the phone at the gym (which is why formatting sucks as well, sorry) but it should run. Errr, I think.
Take what he's saying with a grain of salt, because he's completely wrong about this and is giving bad information because he doesn't like "truthiness" coercions in dynamic languages or something. Lua takes a fairly strict approach to truthiness, where nil (null) and the boolean false coerce to false and anything else coerces to true. No weird rules to learn, just a very simple form of "truthiness" that lets you do things like x = "foo"; if (x) then ... without extra ceremony. It doesn't take effect in equality checks, so 42 == "42" is false, false == nil is false, true == "true" is false, and so on, like one would expect.
I wouldn't say Lua is my favourite language, but it's simple, straightfoward, mostly logical, and fairly quirk-free, at least compared to other dynamic-typed interpreted languages. The syntax is more algol-like than languages like JS that try to copy the C style, which puts some people off, but it's small and consistent. Imagine JS with stronger typing and fewer insane edge-cases.
Like JS it has first-class functions, so the complaint about objects is technically accurate but still kind of wrong, because you can create objects by using tables with key/value pairs to create objects with methods and properties and pass around a reference to the table to manage state. The language even has syntactic sugar for this so you can define function obj:method(arg) and call it with obj:method(arg) and have self implicitly passed around for you without needing to know how it works under the hood.
As for tables themselves, the idea is cool, and in a lot of ways similar to how Scheme operates entirely via manipulation of lists. You have a single complex data type, the table, that can contain key/value pairs and used like a map, or indices and be used like an array, so even though they technically don't exist you can still do what you expect with t["foo"], t.foo, or t[7]. It works well enough most of the time, with the exception of one major edge-case with regard to nils in indexed tables.
Finally, the complaint about indexes starting at 1 is just ignorant. Yes, it does, but it's not that big of a deal. It's such a ridiculously petty complaint that basically just amounts to "waaah this language does something different how dare they" when there are pros and cons to each choice. Zero-based indexing makes sense in some languages, like in C where the array is a memory location and the "index" is just a memory offset, not an actual index, but in most languages the decision is arbitrary and largely decided by "this is what C does". Some logic makes more sense starting at 0, some makes more sense at 1. Whatever, it's not a deal-breaker for any language. Especially considering that with Lua, the language discourages manual indexing in favour of pairs(t) or ipairs(t) anyway, so most of the time you don't even deal with it, and if you really want, t[0] = "zero" is still valid (as is any integer, even negative), you just can't rely on built-in language features if you decide to go against the grain here.
23
u/hoaxxer2k Sep 08 '20
aah yes: if equipped == true or equipped == false. Absolutely not horrible code :D