lua-users home
lua-l archive

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


Miles Bader <miles <at> gnu.org> writes:
> chris <csrl <at> gmx.com> writes:
> > Not in the context I'm working within.  The issue nearly becomes a
> > mute point if one knows the data structure, and so wouldn't be under
> > discussion.
> 
> Er, what's the point of the discussion, anyway?

At this point, I'm not really sure... most likely it is just residue of having
yet another person track through an apparently long standing puddle of mud. :/

> > it makes better sense to expose the sequence length through a
> > table.len() function to avoid this type of confusion.
> 
> Maybe (I dunno) it would be good to also habe a table.len function,
> which does a slow but reliable count for all types of tables, but of
> course the # operator still has a valuable place.

That is exactly opposite my point.  The table.* api is for sequences, it
wouldn't make sense for a table.len() to return the number of all non nil values
in the table, as that'd break away from table.* api being for sequences.

In no way am I discounting the usefulness of the functionality of the length
operator (once understood), but rather how/where that functionality is exposed,
specifically for sequences.  If the length operator was generally useful for all
table types, then it makes sense as an operator.  But as is, it is only useful
for sequences, as such it should be exposed with the rest of the api made
specifically for sequences.

Following the train of thought, I'd suggest that the length operator always
return nil unless a __len metamethod exists.  For people working with sequences
it becomes trivial to wrap the proposed table.len() function inside that meta
method.  Now it becomes explicit that the table creator knows the table is a
sequence.

chris