[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Extending Lua for multiple light userdata types
- From: Javier Guerra Giraldez <javier@...>
- Date: Wed, 14 Nov 2012 09:04:46 -0500
On Wed, Nov 14, 2012 at 8:34 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
> In particular: for table indexing, floats with integer values would
> be converted to integers (as Lua already does internally). So,
> next({[1.0] = true}) would be 1.0, not 1.
not sure i follow you.
currently next({[1.0]=true}) returns 1.0, but the key is internally
just '1' (well, it's not a key, but an index on the array part), it's
converted to integer when entering array code, and back to float when
returned to Lua code.
if the "float with integer values are converted to integers" is
conserved, then i'd guess that {[1.0]=true} is exactly the same as
{1]=true}. And if Lua gets an integer subtype, it would be natural to
return array indexes as integers.
so, i'd expect next({1]=true}) returns 1 and next({[1.0]=true}) would
have to be the same, unless it kept the original float key.
--
Javier
- References:
- Extending Lua for multiple light userdata types, Rena
- Re: Extending Lua for multiple light userdata types, Dirk Laurie
- Re: Extending Lua for multiple light userdata types, Rena
- Re: Extending Lua for multiple light userdata types, Dirk Laurie
- Re: Extending Lua for multiple light userdata types, Rena
- Re: Extending Lua for multiple light userdata types, Coda Highland
- Re: Extending Lua for multiple light userdata types, liam mail
- Re: Extending Lua for multiple light userdata types, Roberto Ierusalimschy
- RE: Extending Lua for multiple light userdata types, Richter, Jörg
- Re: Extending Lua for multiple light userdata types, Roberto Ierusalimschy
- Re: Extending Lua for multiple light userdata types, Roberto Ierusalimschy