Still seems to me that a second return value from type() is by far the most
straight forward solution to this. Anyone who does not like this can easily
front it with a wrapper in Lua to do it however they wish.
This could also be usefully extended by a new '__type' metatable key. If
present, its value would be returned as the second return from type(). So
classes/types created from table or userdata type could easily be set up to
return an appropriate sub-type.
> Date: Mon, 22 Jul 2013 09:04:59 +0200
> From: David Demelier <demelier.david@gmail.com>
> Subject: Re: Lua 5.3 work1 Considering math.isinteger or type()
> To: Lua mailing list <lua-l@lists.lua.org>
> Message-ID:
> <CAO+PfDfs6ke3Gpko8n4NTU6imm2-
> Bkxj5osgSNf2Y32yR2o_zQ@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2013/7/19 Philipp Janda <siffiejoe@gmx.net>:
> > Am 19.07.2013 10:00 schrC6bte Pierre Chapuis:
> >
> >>> Well, my suggestion of sticking debug.subtype() inside type() was
> >>> meant to sidestep the issue of where to put it, while keeping the
> >>> API function count low. I'm not strongly advocating it, just
> >>> contributing
> >>
> >>
> >> For what it's worth, I agree with that idea.
> >> I really don't like the idea of putting subtype() in debug.
> >
> >
> > I'm fine with `debug.subtype`, although I probably would call it
> > `debug.type`, just like `debug.setmetatable` provides a superset of
> > functionality compared to plain `setmetatable`.
> >
> > But do we need that function at all? Are there any use cases where
> you
> > want to know the actual subtype of functions or userdata in Lua code,
> > or is this just for the sake of completeness?
> >
> > At the moment, my preferred solution would be math.type (like
> io.type,
> > lpeg.type, etc.):
> > * no new global variables
> > * no new names
> > * no unfamiliar calling conventions
> > * if people remove debug functions, they probably won't make an
> exception
> > for harmless functions like (sub)type
> > * the only reason to remove `math` is if you don't have floats in
> which
> > case this function becomes obsolete anyway
> >
>
> Yes, math.type looks absolutely the best solution!
>
