table.type sounds better, the problem with getmetable().__name doesn't look that bad, __name was added recently, and I'm sure some people on older versions were doing something worse
On 24 Dec 2020, 17:28 +0300, DarkWiiPlayer <darkwiiplayer@hotmail.com>, wrote:
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? :-)
