[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: table.new in 5.3?
- From: Philipp Janda <siffiejoe@...>
- Date: Thu, 21 Nov 2013 04:35:14 +0100
Am 21.11.2013 02:22 schröbte Andrew Starks:
On Wednesday, November 20, 2013, Philipp Janda wrote:
Am 20.11.2013 23:24 schröbte Andrew Starks:
What do you think about something like `getudtype(userdatavalue)`,
What for? You are not accessing the userdata's memory directly from Lua so
you don't *need* the actual userdata type for type safety, and if you check
for it anyway you run into the same issues as with function/is_callable,
i.e. you lose the ability to pass e.g. a mock object instead of the real
thing (or an object "writing" to an array instead of a real file object) ...
I'm parsing input from LPEG. I'm working with both int64 and a real number
(media_time / media_scale). What is int64, realnum or LPEG? All are
userdata. All are happy with -+/*. Most often I get an error. Sometimes I
The downside would be that your code stops working if you start using
LuLPeg or Lua 5.3 with its native int64 type (don't know about
LuaJIT's cdata types).
There already are `io.type` and `lpeg.type`, but luckily I haven't seen
those very often. I have however seen at least four different
replacements for Lua file handles (in LuaAPR, LuaRocks, LuaZip, and
Also, functions in Lua work like you describe (mostly). Many C functions
called by Lua don't.
No, and C functions usually call `luaL_checkudata`. I don't doubt the
usefulness of `luaL_checkudata` on the C side (in fact I would like to
have more type information in the resulting error messages), but this is
about a `getudtype` Lua function. Polymorphism in C is a lot harder than
in Lua ...
There is no "tonumber" that the math library calls, so
I end up wrapping that up.
LPeg's `+` operator doesn't call tonumber on its operands either, and
you don't want it to, because you would lose type information. (I have
made peace with Lua's automatic string<->number conversion by now). A
generic math library that works transparently on lua_Numbers, BigNums,
rationals, complex numbers, etc. would be very nice, but since Lua's
math library relies on C's, we only get those functions for doubles. And
if you can't support polymorphism anyway, checking the actual type is
the next best thing, but for userdata you can do that with
`luaL_checkudata` on the C side.
As a convenience, whenever I call `type(v) == "userdata"`, it strikes me
that, as a Lua user, I never care if it's really a "userdata." At that
point, I've designed program such that I'm checking for a particular kind
of userdata so that I can take some sort of exceptional action to do
whatever is needed to get it into whatever I was expecting or, more likely,
whatever some other library expects.
Userdata often has metamethods beyond __call, including +*/ etc. so long as
that's the case, there will be ligitamate times where knowing the true type
of a userdata value results in the clearest, simplest code.