šŸ“ƒ 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.
0
Load More
→