Reported to the Bloat Police: string.pack, .unpack and .packsize!

["John Hind" <john.hind@...>]

Good grief, how did this feature get past the Bloat Police?

Good ideas have been poopood here because they involve a couple of extra
lines of C and a few words of documentation, yet a massive 500 line system
for a highly specialised use-case gets in! Not to mention yet another
arbitrary syntax with zero learnability (to join such bug-inducing horrors
as escapes in string literals, regular expression patterns and string format
codes) and what must be a huge increase in required test cases.

The only use-case I can think of for this which could be implemented in
base-line Lua without other add-on libraries is reading and writing
proprietary binary file formats, surely a legacy case in these days of data
interchange by formatted text standards such as XML, Json and even Lua
itself! Sure it will be useful for interop marshalling and protocol support,
but those uses require add-on libraries anyway so pack/unpack may as well
also be an add-on library. Does it even have a significant advantage over
ad-hoc implementation in Lua, especially now bitwise operations are
available?

At the very least, this ought to be a sub-library like coroutines so it can
be included/excluded independently of the rest of the string library.

Given it can be justified at all, the feature should be more flexible. The
byte orientation is unnecessarily restrictive: it should support any length
of signed or unsigned integer from 1-bit up to the size of lua_Unsigned and
it should not require these to be byte aligned. This would better support
protocol and hardware register mapping. And why do the codes have to be
single letters? I envisage something like:

"uint8,bool,bool,int32,float16,pad8,6string,string8"

Where pad8 means pad to a byte boundary, 6string means string with a six-bit
count prefix, string8 means string with an 8-bit zero terminator.

I'm genuinely baffled by the decision to include this: was it really
considered to have a significantly more common use-case than all the stuff
deprecated from the math library (which I am happy with, incidentally)?



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus