Re: Make type respect __name and add rawtype

[DarkWiiPlayer <darkwiiplayer@...>]

Yes, in a way I understand why you wouldn't want `type(something) ==
"table"` to break, but at the same time, that's kind of the point of the
whole thing: to have a mechanism to tell other code that something is
*not* a table as far as it is concerned. That code should then be
expected to treat it as an opaque object, just as it would with
userdata. Just as with table indexing, and `__index`, where the indexing
code also just takes the returned value without asking questions. If
you'd have to use first `type`, then `table.type` if it's a table, that
really defeats the purpose of metaprogramming: at that point you can
just as well expect others to read `getmetatable(something).__name`
manually.

On 24/12/2020 14:45, Egor Skriptunoff wrote:
> On Thu, Dec 24, 2020 at 1:54 PM DarkWiiPlayer wrote:
>
>     if changing the behavior of `type` is considered a bad idea
>
>
> IMO, it's a bad idea to break compatibility with widespread check:
> if type(v) == "table" then
>  
>
>     I'd love to at least see some other function that behaves like this
>
>
> The similar problem with numeric subtype was solved by introducing
> math.type()
> So, it might be a good decision to introduce table.type()
> If there is no "__name" metafield, table.type() may return
> "table"/"userdata"
>
> You may ask:
> Why should this function be located in the "table" library while it
> should work with both tables and userdata?
> My answer:  Why not?
> We already have functions in the "math" library working with strings:
> math.min(), math.max()
> math.min("11", "2") == "11"  -- contra-mathematical behavior
> So, why not have a function in the "table" library working with
> userdata?  :-)
>