[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua 5.3 work1 Considering math.isinteger or type()
- From: Thijs Schreijer <thijs@...>
- Date: Tue, 23 Jul 2013 14:03:00 +0000
Being the one that opted for the two return values, I must say that I agree with Steve and Roberto that having to create a local for just accessing the second return value is a bad practice.
Then I would rather have a single type() function and replace its 'number' return value with the new types. Big incompatibility but the new integer division operator already is. Incompatible but clean.
-------- Original message --------
From: John Hind <firstname.lastname@example.org>
Subject: Re: Lua 5.3 work1 Considering math.isinteger or type()
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 <email@example.com>
> Subject: Re: Lua 5.3 work1 Considering math.isinteger or type()
> To: Lua mailing list <firstname.lastname@example.org>
> Content-Type: text/plain; charset=UTF-8
> 2013/7/19 Philipp Janda <email@example.com>:
> > 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
> > 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
> > 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
> > for harmless functions like (sub)type
> > * the only reason to remove `math` is if you don't have floats in
> > case this function becomes obsolete anyway
> Yes, math.type looks absolutely the best solution!