[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: table.new in 5.3?
- From: Thijs Schreijer <thijs@...>
- Date: Thu, 21 Nov 2013 09:26:35 +0000
Did this thread just get hijacked?
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On
> Behalf Of Philipp Janda
> Sent: donderdag 21 november 2013 4:35
> To: firstname.lastname@example.org
> Subject: Re: table.new in 5.3?
> 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
> >> you don't *need* the actual userdata type for type safety, and if you
> >> for it anyway you run into the same issues as with
> >> i.e. you lose the ability to pass e.g. a mock object instead of the
> >> 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
> > (media_time / media_scale). What is int64, realnum or LPEG? All are
> > userdata. All are happy with -+/*. Most often I get an error. Sometimes
> > don't.
> 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).
> : http://lua-users.org/lists/lua-l/2013-06/msg00196.html
> 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
> > 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
> > whatever some other library expects.
> > Userdata often has metamethods beyond __call, including +*/ etc. so long
> > that's the case, there will be ligitamate times where knowing the true
> > of a userdata value results in the clearest, simplest code.
> > IMHO.
> > -Andrew