RE: table.new in 5.3?

[Thijs Schreijer <thijs@...>]

Did this thread just get hijacked?


> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Philipp Janda
> Sent: donderdag 21 november 2013 4:35
> To: lua-l@lists.lua.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
> 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
> > don't.
> 
> 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).
> 
>    [1]: 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
> 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.
> >
> > IMHO.
> >
> > -Andrew
> >
> 
> Philipp
> 
>