[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Array subtype is conceptually simplest
- From: Sean Conner <sean@...>
- Date: Fri, 2 Nov 2018 16:15:21 -0400
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
> > <email@example.com> 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 :
* 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
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)
Also available via LuaRocks as org.conman.cbor