lua-users home
lua-l archive

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

Attached is 'type.lua' that extends current 'type()' in a couple of ways, and a note I've done about this on my LUA52-FEATURES wish list.

Still returning "userdata" as the first return value means, current code would hardly ever be broken.



"I'd like luaL_typerror (or luaL_typename) to try a __type metamethod.
Currently, I have to modify it, so "number expected, got table" can
become "number expected, got Sprite"." (Glenn Maynard on the List)

Could also be made so, that type() would return a second value, if there's a __type metamethod.

luaSub does this by overriding 'type()' and checking for 'tag' (userdata
families) and 'etag' (enums) values in the userdata's metatable. This solution
is of course luaSub specific.

Userdata returns "userdata" [,family_str] and enums "enum", family_str.

Solution:   Lua could adopt luaSub's 'type.lua'

Attachment: type.lua
Description: Binary data

Greg Fitzgerald kirjoitti 19.1.2008 kello 2:44:

Would there be any downside to Lua's 'type()' returning the value of a '__type' metamethod if its type is 'userdata'?

That is, this behavior (but done in the VM):

local oldType = type
function type(x)
   local t, mt = oldType(x), getmetatable(x)
   return t == "userdata" and mt and mt.__type or t

The reason I ask is that I'd like to be able to create a C library that add new types in such a way that there would be no way for a Lua user to know those types were implemented with userdata and not by modifying the VM. The binary and unary metamethods get us most of the way there - just need a type metamethod to complete the abstraction.