Re: Array subtype is conceptually simplest

[Sean Conner <sean@...>]

It was thus said that the Great Pierre Chapuis once stated:
> On Wed, Oct 24, 2018, at 09:53, Dirk Laurie wrote:
> > Op Di., 23 Okt. 2018 om 17:56 het Luiz Henrique de Figueiredo
> > <lhf@tecgraf.puc-rio.br> geskryf:
> > >
> > > Wouldn't an array *library* be a simpler solution?
> 
> > So no, an array library would not be a solution at all, unless
> > accompanied by an "apairs" function in the standard library.
> 
> If the array library is a standard library then such a function could
> be included in it (`array.apairs(my_array)`, maybe with a method as
> well: `my_array:apairs()`).
> 
> To add my (very simple) opinion, I don't care about the features at
> all, as long as there is a *standard* way to detect that something
> should be treated as a sequence / array / whatever, so we can all
> stop using weird codebase-specific tricks when serializing / deserializing
> data to / from any format that looks like JSON.

  Here's how I handle that situation in my CBOR library [1]:

	* If the table has a defined length (that is, #t > 0) it is treated
	  as a sequence and stored as a CBOR ARRAY.

	* Otherwise, it is treated as an assiciative array and stored as a
	  CBOR MAP

  The user can override this by setting a __tocbor metamethod on the table
and explicitely encoding the table as a CBOR ARRAY or MAP (by calling the
appropriate method directly).  That was the most straightforward method I
found for handling this.

  -spc (The __tocbor is also honored on any userdata passed to it)

[1]	https://github.com/spc476/CBOR
	Also available via LuaRocks as org.conman.cbor