Re: Feature Request: type() consult __type for userdata

[Asko Kauppi <askok@...>]

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.

-asko


=== __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  
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
> end
>
> 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.
>
> Thanks,
> Greg