[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: table.len
- From: "Soni L." <fakedme@...>
- Date: Sun, 7 Aug 2016 13:29:46 -0300
On 07/08/16 01:24 PM, Soni L. wrote:
On 07/08/16 12:59 PM, Philipp Janda wrote:
Am 07.08.2016 um 17:41 schröbte Soni L.:
table.len = function(t)
assert(type(t) == "table", "bad argument #1 to 'len' (table expected,
Most of the table library now can work on userdata with suitable
`__index`/`__newindex`/`__len` metamethods defined, so this seems
like a step in the wrong direction. Maybe we should get rid of (or
deprecate) `string.len` instead. It is superfluous since we have the
Perhaps the table library should be renamed.
string.len does type checking.
Also the # operator is stupid.
: http://sprunge.us/NBFO (Not counting that if len was a function
instead of an operator, we'd be able to replace len algorithm
Uh can't edit emails:
Benefits of len as a function:
- Can get len based on __index instead of forcing userdata or tables to
- Can be replaced on-the-fly to change length algorithm.
- Can be replaced to ignore __len entirely.
- Can be tweaked by sandboxes.
- Free 0-indexing support. (this might count as a drawback depending on POV)
- Function call overhead.
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.