lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> Ahh yes. Your use case is very unique, in that it is pretty
> much all about putting Lua values into a very strict
> buffer/message passing system.

I see it being useful for that, yes, but not *only* for that. I also
see it being useful for anyone who wants truly strongly-typed structs,
as I have sometimes wanted when programming in Lua.

For example, if you are manipulating ASTs that have a well-defined
schema, the library could be useful for that even if you aren't
actually parsing or serializing messages. But the fact that the
structs would be easily parseable and serializable to many different
formats would be a bonus.

> It's an interesting and tricky design choice that you're
> facing. Imagine that I'm a sure and I've got a fancy metatable
> that makes my content bend into a specific protobuf... I
> assume that you're doing normal table access and not raw,
> correct? I'm only curious.

Actually my plan is to store primitive values (numbers and booleans)
in the userdata directly as raw bytes, where each field is stored at a
known offset. Strings, arrays, and submessages would be stored in the
userdata's "userval" (or environment table for 5.1) at known array
offsets. This eliminates the need to have a key/value hash table for
each instance. This is sort of like Python's __slots__.

> Do you envision this being a Lua project, or only LuaJIT?
> We're looking at a protobuf solution, which is why i ask.

The code does not depend on LuaJIT at all. Where it is JIT-ting, it is
using DynASM *directly* (ie not through LuaJIT).

I might write some optimized getters/setters for LuaJIT, but it would
an optimization that is only enabled when LuaJIT is present. Otherwise
it will all be straight Lua.

On Mon, Jan 6, 2014 at 1:42 PM, Andrew Starks <andrew.starks@trms.com> wrote:
>
> On Mon, Jan 6, 2014 at 11:37 AM, Josh Haberman <jhaberman@gmail.com> wrote:
>>
>> I think I have this covered, because the schema can be
>> defined/extended in Lua, so if the user wants to extend the struct
>> they just extend the schema.
>
>
> Ahh yes. Your use case is very unique, in that it is pretty much all about
> putting Lua values into a very strict buffer/message passing system.
>
> In that case, take all of my answers and assume that my advice would be to
> do almost the opposite! :) I'm only kind of kidding here, but hopefully you
> take my meaning...
>
> It's an interesting and tricky design choice that you're facing. Imagine
> that I'm a sure and I've got a fancy metatable that makes my content bend
> into a specific protobuf... I assume that you're doing normal table access
> and not raw, correct? I'm only curious.
>
> Anyway, it sounds like, under the circumstances, a more type-oriented
> approach is appropriate here, than would otherwise normally be. Perhaps
> "idiomatic" is not what you're after here?
>
> -Andrew