Re: table.len

["Soni L." <fakedme@...>]

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.:
> > > How about
> > >
> > > table.len = function(t)
> > >   assert(type(t) == "table", "bad argument #1 to 'len' (table expected,
> > > got "..type(t)..")")
> > >   return #t
> > > end
> >
> > 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 
> > length operator.
> >
> > Philipp
> Perhaps the table library should be renamed.
>
> string.len does type checking.
>
> Also the # operator is stupid.[1]
>
> [1]: http://sprunge.us/NBFO (Not counting that if len was a function 
> instead of an operator, we'd be able to replace len algorithm 
> on-the-fly.)
Uh can't edit emails:

Benefits of len as a function:

- Can get len based on __index instead of forcing userdata or tables to 
define __len.
- 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)

Drawbacks:

- 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.