Re: About a week with LUA_NOCVTN2S and LUA_NOCVTS2N
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: About a week with LUA_NOCVTN2S and LUA_NOCVTS2N
- From: Sean Conner <sean@...>
- Date: 2015年1月23日 17:07:46 -0500
It was thus said that the Great Andrew Starks once stated:
> I compiled Lua with the LUA_NOCVTN2S (no coercion from numbers to
> string) and LUA_NOCVTS2N (same, but from string to numbers).
[ ... ]
> 5: I like programming with it and will always have it turned on.
What I find annoying is that lua_isnumber() and lua_isstring() return true
when it's *either a number or a string!* I've been bitten by that enough
times you'd think I'd have learned by now, but no ... I still get bit from
time to time.
But, even though I might be prompted to define LUA_NOCVTN2S or
LUA_NOCVTS2N, doing so breaks the C API and C modules that rely upon the Lua
5.1/5.2 behavior break in subtle ways. I would think that the manual for
Lua 5.3 should mention that
lua_isstring()/lua_isnumber()/lua_tostring()/lua_tonumber() might have
different semantics.
> I like it because I suffer from *Abstraction Anxiety*: A general fear
> of abstractions, especially ones that perform magic tricks without
> explicit instructions to do so. (I'm still working on that
> definition... I think it's very common amongst Lua folks)
You're not alone. There's the famous Joel Spolsky article "The Law of
Leaky Abstractions" [1], and this lesser known bit, "Does Abstraction
Scale?" [2] I know in my own code, I try to avoid needless abstractions,
but sometimes, I fall into the trap.
At work, I'm in the process of enumerating test cases for a regression
test. I wrote code so that I could do:
for A in bools() do
for B in list { 'variation-a' , 'variation-b' , 'variation-c' } do
for C in list { 'c1' , 'c2' } do
for D in bools() do
...
which closely minics the actual language used to describe the test
conditions:
A can be on or off
B can be variation-a, variation-b or variation-c
C can be either c1 or c2
D can have two options
...
Sure, I could have written those as:
for _,A in ipairs { false , true } do
for _,B in ipairs { 'variation-a' , 'variation-b' , 'variation-c' } do
for _,C in ipairs { 'c1' , 'c2' } do
for _,D in ipairs { false, true } do
...
but a) it's more typing [3] and b) it doesn't express what is going on
succinctly enough. So what if I had to write a few functions (bools() and
list()) to gain this, ipairs() is already a function so it's not like I'm
loosing any performance over this.
I should also note that I'm the only Lua programmer in the company (and
the other programmers in my department tend to use Perl or Python as their
"to-go" scripting language).
-spc (and that '...' lists about another seven conditions)
[1] http://www.joelonsoftware.com/articles/LeakyAbstractions.html
[2] http://thoughtstorms.info/view/doesabstractionscale
[3] Which, oddly enough, is an argument I almost never make. In my
opinion, trying to reduce the number of keystrokes when writing code
often *adds* to the cognitive load of knowing that the code is doing
and it becomes more dense and hard to follow.