lua-users home
lua-l archive

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


On Sun, Jun 15, Rena (hyperhacker@gmail.com) wrote:

>On Sun, Jun 15, 2014 at 5:49 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
>>On Jun 15, 2014, at 1:15 PM, Andrew Starks <andrew.starks@trms.com> wrote:
>>
>>
>>
>> This is stating something that is very obvious to you guys, but upon thinking about it, the distinction between the *table* library and a
>> non-existent library that works with tables + their defined behaviors, aka "objects", becomes important. The same holds for theath library, which also does not work with anything except numbers (or >strings that can be numberfied).
>>
>> Assuming nothing about Lua were to change, I would find it clarifying, if I haven't missed something that is already present, if there was something that emphasized that distinction:
>>
>> "Except for a few exceptions, Lua's standard libraries work with Lua's basic types and do not check for a metatable or metamethods, when manipulating or accessing them."
>>
>> Another sentence or three on why this is the case and how these libraries may be built upon to handle "object-like" values, would be good, too.
>>
>> What is obvious to the designer or to the CSCI degree holder can look confusing and inconsistent to someone without mental access to the broader issues.
>>
>> -Andrew

>Yes, you are quite right that this is a part of the problem. On the one hand, tables are just the Lua basic collection type. On the other, they are abstracted via metamethods to form one (common) way to >realize OO type behaviors. This slightly schizophrenic model means that table.sort() gets caught in the middle. If we view table.sort() as a fast way to sort data, then raw get/set makes sense. If we view >it as a generic function that sorts anything that has numeric indexing and a length, then it needs to use metamethods. In fact, in this model, table.sort() could apply to userdata as well, and probably >doesnât really belong in the table library at all. Iâm not saying this is good (it probably isnât), but the current design does make Lua a little inconsistent, and perhaps generates surprise when people are >learning the language, as per the OP.
>
>âTim



This is the kind of reason I feel like the table library could be split/renamed to an array library.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It could be split or renamed into an array library, yes, but it should not under ordinary circumstances upset anything to check for a metamethod before beginning table.unpack()'s loop.  I do see potential trouble if someone has created an infinite proxy table or integer-indexed object (that is to say, one that can be indexed with all of the natural numbers in order and never give a nil) and attempts to unpack it.  An __unpack metamethod seems to be the most prudent approach.  Thanks go to the poster who suggested a replacement table.unpack(...) function (not quoted above.)  That may be what we do, but I hesitate to create an in-house Thermo "dialect" of the standard Lua libraries.

The surprise came largely because PIL, 3rd Edition's Lua equivalent of table.unpack() differed from the real table.unpack().  The problem could be said to be with PIL.

Thanks, all, for the enlightening discussion.  I apologize for just throwing it out there and leaving; after the first post I was away at the mass spectrometry conference.

Sincerely,
Ben Kalafut