lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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[1] 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 Penlight).

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.