šŸ“ƒ SLua Alpha

General discussion and feedback on Second Life's SLua Alpha
lljson encode and decode functions with vectors, quaternions, and UUIDs.
Right now, vectors and quaternions encode to strings and decode to strings with the "<... >" format. Likewise UUIDs decode to strings. This is a major nuisance to scripters when decoding tables with embedded vectors, quaternions or UUIDs, requiring special decoding functions in each and every script using them. The underlying problem is that at present there is no way to differentiate between an encoded vector, quaternion, or UUID and the equivalent string value. i.e vector(1,2,3) and "<1,2,3>" both encode to "<1,2,3>". I'd like to propose a variation to encode/decode, (call them lljson.pack and unpack or better, perhaps, add an optional EncodingType argument to encode and decode), that when a vector or quaternion is encountered, encodes them as they are now. UUIDs would then be encoded by adding the same <> delimiters around the current UUID string. When a string starting with < and ending with > is encountered, encode it adding an extra < and > at each end, then decode such strings by removing the added < and >. Then the vectors, quaternions, and UUIDs can be uniquely identified as such by the undoubled delimiters and the appropriate internal format and decoded directly to the appropriate type. This would allow the encoding and decoding of all SLua types in tables without special intervention by the scripters--significantly simplifying scripting such operations and greatly improving performance (one optimized pass through the data in C, rather than one in C followed by one of random scripter quality in SLua) when passing tables between scripts, or storing and retrieving tables in Linkset Data. The only reason for keeping encode and decode as they are now is for the sake of compatibility with external json operations and even then if vectors, quaternions, or UUIDs are involved the proposed operations would likely be superior as it would be necessary to make accommodations for these types on the remote end anyway.
13
Ā·
planned
Table lengths, concatenation, and probably other things!
Currently there are surely a lot of little parity problems. These are just some that I've noticed so far- local a = {1, 2, 3, 4} local b = {1, 2, nil, 4} local c = {1, 2, d = 3, 4} ll.OwnerSay(`a {#a} `) ll.OwnerSay(`b {#b} `) ll.OwnerSay(`c {#c} `) A and B will return 4, but C will return 3. Getting the length of a table with dictionary elements requires looping thru the entire table with pairs() each time, requiring a cludgy metamethod to have it work how one would 'expect', when just a table.len() would be useful. local Tbl = {} Tbl.__index = Tbl Tbl.__len = function(len) local incr = 0 for _ in pairs(len) do incr = incr + 1 end return incr end Likewise, list concatenation is a major thing in SL, allowing one to build up lists for llSetLinkPrimitiveParams for instance to save on function calls. This is entirely impossible in Lua with merging even two tables requiring your own function, or another cludge, to say nothing of matching the functionality of SL where multiple lists can be strung together easily- Table. __concat = function(a, b) if type(b) == "table" then for _, v in ipairs(b) do a[#a+1]=v end else a[#a+1]=b end return a end } As these are probably minor, basic functions that would get a lot of use, I feel like small things like this should start being added to the language, to prevent them from needing to be created in every script itself. The performance would also be higher if implemented in C on top of that. Lua is advertised as being an extremely tiny language, but that can be a little detrimental when we have to make even basic helper functions ourselves in our limited 64kb memory.
4
Ā·
tracked
Load More
→