lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Thursday, July 18, 2013, Hisham wrote:
On 18 July 2013 21:39, Andrew Starks <> wrote:
> On Thursday, July 18, 2013, Hisham wrote:
>> On 18 July 2013 14:16, Roberto Ierusalimschy <>
>> wrote:
>> >> 2013/7/17 Roberto Ierusalimschy <>
>> >>
>> >> >  but I do
>> >> > not think the change is worth the trouble. Just imagine the endless
>> >> > discussions about what functions should go there...)
>> >> >
>> >>
>> >> I see. Maybe the discussion should not be about "what should go there",
>> >> but
>> >> about what should not stay in debug, and move them gradually either to
>> >> "there" or to global. "There" would become clearer in the proccess.
>> >
>> > For me, the main problem is not debug versus "there". It is global
>> > versus "there". (Not to mention a lot of incompatibilities for what
>> > many may consider nitpicking.)
>> Well, my original suggestion was math.type() (and the parallel with
>> io.type() is indeed nice), but since we're throwing suggestions out
>> there, here's yet another one: if this is to be made more general than
>> just for math, then maybe just add the feature to type() itself, as in
>> type(v [, mode]) -- if given a second argument (true?) then type
>> returns the specific subtype, if not, the general type.
>> -- Hisham
> Hisham,
> Sorry To repeat myself... I'd be interested in your critique of:
> type.isfloat(x); type.isnil(x)

It doesn't look bad as APIs go, but it's a half-dozen functions at
least and an extra library, plus the incompatibility of turning type()
from a function into a table (yes, it could be made into a callable
table via metatable magic but it's extra complication). For these
reasons it doesn't strike me as something that would make into the Lua
standard library. The Lua team seems to always favor minimalistic and
generic approaches (case in point, them turning the issue of telling
apart floats and integers into a single general subtyping function
that also handles userdata and function differences, etc).

-- Hisham

Thanks for that. I was thinking a functable with is[typename] was more generic than a mode signified by true/false. I'll have to think on that.