Re: Common FFI declarations
- From: Mike Pall <mike-1205@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 9 May 2012 15:45:17 +0200
William Adams wrote:
> I have a declarative thing that allows me to do this sort of thing:
>
> IPv6Header_Info = {
> name = "IPv6Header";
> fields = {
> {name = "version", basetype = "uint32_t", subtype="bit", repeating = 4};
> [...]
I realize how addictive meta-programming gets. But I think you're
falling into the hole you dug yourself. That's exactly what C structs
are made for, so why not use them?
Inventing your own half-baked syntax to describe a struct is
_exactly_ what I tried to avoid with the FFI. What about nested
structs, unions, structs of arrays or arrays of structs. You
really, really want to reinvent the full expressiveness of C?
We can discuss about the merits of C syntax all day long, but when
it comes to data description it's a pretty good compromise between
conciseness and readability. Best of all: the readers of your code
don't have to learn a new pseudo-language and someone else already
took care to write down and verify all of those pesky declarations.
> header = IPv6Header(buffer, bufferlen)
> header:get_version()
> header:get_nextheader()
> header:set_destination(destbytes)
Just cast or copy that buffer to a struct and handle the fields
with the regular accessor syntax:
header.version
header.nextheader
header.destination = destbytes
> Through the cleverness of code, these 'set_' and 'get_' can be
> turned into regular table field accessors as well.
I disagree. I don't think it's particularly clever to create an
unneeded and expensive abstraction that goes full circle.
--Mike
Other related posts:
