[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Feature Request: type() consult __type for userdata
- From: Asko Kauppi <askok@...>
- Date: Sat, 19 Jan 2008 15:22:43 +0200
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.
=== __TYPE METAMETHOD ===
"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
is of course luaSub specific.
Userdata returns "userdata" [,family_str] and enums "enum", family_str.
Solution: Lua could adopt luaSub's '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
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