[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: io.format (was: Reported to the Bloat Police: string.pack, .unpack and .packsize!)
- From: Dirk Laurie <dirk.laurie@...>
- Date: Fri, 21 Aug 2015 14:36:19 +0200
2015-08-21 13:05 GMT+02:00 John Hind <john.hind@zen.co.uk>:
> For academic reasons, I just wanted to understand the rationale and
> the use cases for this. So far I've seen a lot of hand-waving but no
> convincing use case compelling enough to justify this being part of
> the language rather than an add-on library.
There is a lot of history behind this. From the work2 version on,
Lua 5.3 offered support in the string library for binary serialization
of numbers.
work2: packfloat, packint, unpackfloat, unpackint
work3: dumpfloat, dumpint, undumpfloat, undumpint
All these had parameters for the size and endianness
of the desired representation, as one-character strings.
It was pointed out by list members (I must take some of the
blame here) that one might as well have one string parsed
as size/endianness pairs, accept varargs in dump and return
multiple values in undump.
There was also a certain amount of ridicule (ditto) for the
ungainliness of the names: "undumpint, undumpint, undumpint".
Still they survived in alpha. Beta, though, included basically
the full "struct" module of Roberto, which had been mooted
by him as one of four major innovations being considered
for 5.3 (utf8, 64-bit integers and lpeg were the others).
So, the right time for the Bloat Police to pounce would
have been just after beta, or during the tenure of rc1
and rc2. Instead, we marvelled at the sheer elegance of
string.pack and the possibility to use it in an object-oriented
way. The only further change was the addition of packsize.
If you don't like it, undump it.