Re: table.pack()

[Patrick Donnelly <batrick@...>]

Hi Renato,

On Sat, Jan 23, 2010 at 5:39 AM, Renato Maia <maia@inf.puc-rio.br> wrote:
>
> On 22 Jan 2010, at 19:47, Patrick Donnelly wrote:
>
>>> That being said, I wonder, which one is better and why... What do you
>>> think?
>>
>> So to answer your question, neither :)
>
>
> I agree with Patrick here. However I'd go a little further and vote for no
> 'table.pack' at all. I agree it is useful in some cases and people write
> something like that often (as does 'string.split', 'table.append',
> 'table.copy', ...). But I don't believe there is one-version-fits-all to
> make it into a standard library. Furthermore, the asymmetry with
> 'table.unpack' [1] and bringing back the 'n' field policy does not look like
> the best choice either. Personally, I'd rather see 'apairs' [2] becoming
> standard.

I would agree that using an 'n' field is an odd about-face for Lua
after the changes in 5.0 -> 5.1. It would be easier to just return a
second value and allow the programmer to set his own convention.

I don't agree that table.pack is not useful enough for inclusion. It
is way too difficult to save the return values of a function without
creating a new table. Setting unnecessary standards is one thing,
making a common problem doable is another.

(Table reuse is something I (and many others) feel should be
encouraged but the table library doesn't do enough to make this
possible. Just like packing values into a table, erasing a table is
unnecessarily expensive. There are hacks out there to force a table
resize when this really should just be a library function. The user
doesn't even need to be aware that it resizes the table, only that it
is the standard and fastest way to do it.)

> Whenever possible, the Lua team avoided the introduction of new features or
> standardization of policies and particular solutions. This should be easier
> now with Lua's package model that promotes the use of third-party libraries
> to fulfill particular needs. That's why the standardization of 'bit' and
> 'table.pack' came as a surprise to me.

Right, but this isn't necessarily standardization so much as making
bare-essentials possible. Even applications like World of Warcraft
include a bit library where one would think the very high-level nature
of the game's AddOns would not require something like bit
manipulation. Experience has shown that bit juggling is just as
necessary as basic arithmetic.

-- 
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin