Re: 'table' as fallback for tables

[Thijs Schreijer <thijs@...>]

> On 30 Jun 2016, at 06:18, Philipp Janda <siffiejoe@gmx.net> wrote:
> 
> Am 30.06.2016 um 05:01 schröbte Hisham:
>> On 29 June 2016 at 10:10, Philipp Janda <siffiejoe@gmx.net> wrote:
>>> Am 26.06.2016 um 21:59 schröbte Philipp Janda:
>>>> 
>>>> Am 26.06.2016 um 20:23 schröbte Tim Hill:
>>>>> 
>>>>> 
>>>>> As I said, the scheme is far from perfect, but it’s more consistent
>>>>> that the current incoherent approach of .n, # and sequences imho.
>>>> 
>>>> 
>>>> I agree. Most of it could be realized via a library without support from
>>>> the Lua core ...
>>> 
>>> 
>>> I've modified the standard table library to use `.n` instead of `#`. In case
>>> someone else wants to check out how it feels:
>>> 
>>>     luarocks install --server=http://luarocks.org/dev table.n
>> 
>>> From reading test.lua, the feeling I get is that it feels cumbersome
>> if t={1,2,3} doesn't work with the `table` functions out of the box. I
>> wonder if "use n if present, or else just use #" would be a sensible
>> approach.
> 
> I already use this approach elsewhere, but the downside is that you don't actually get rid of the undefined behavior of sequences with `nil`s. You would probably run into it less often, but that would make it all the more surprising when you do.
> 
>> For the standard library, I think it would be confusing (and
>> perhaps too slow?) in general, but it would make sense for
>> table.unpack.
> 
> Since most of the arguments for `table.unpack()` probably come from `table.pack()`, I agree.

Whenever I use `pack` I also redefine unpack to honour `t.n`. I’ve just been bitten by it too many times. (and I’ve, so far, never been bitten by an unexpected `n` field while doing so)

> 
>> 
>> -- Hisham
>> 
> 
> Philipp
> 


Thijs