LC7 arrayEncode/Decode

[Richard Gaskin]

Peter Haworth wrote:

 > I haven't come across that yet but probably because I base64 encode
 > the array as well as array encode it and don't write to the file in
 > binary mode.

Base64 might be useful for network transfer, but for local storage just 
reading/writing in binary mode will be simpler, faster, and result in a 
much smaller file.

 > Which raises another question.  I'm converting the app to 7.0 to be
 > unicode compliant.  The data in the array will have been textDecoded
 > format. Do I need to textEncode it before base64/arrayencoding it?

LC 7's native array format accounts for Unicode.  It can also encode for 
earlier versions with an optional second argument to the arrayEncode 
function to specify the desired output version (e.g. "6.7").

When decoding arrays, LC 7 automatically detects the version from the 
data and uses the appropriate format, so we don't need to specify a form 
for arrayDecode.

Two tips for encoded arrays:

1. When writing code that needs to be compatible with both v6.7 and 7.0, 
the optional argument with arrayEncode does not throw an error in v6.7. 
  Of course that version can only write in the older format so that 
argument is effectively just ignored, but by not throwing an error you 
can move code back and forth between the two versions without having to 
resort to funky "do" commands.

2. The first byte of an old-format encoded array is numToByte(5), and 
the newer format uses numToByte(6).  It's rare that you'd need to know 
the version of an encoded array, but if you do you can determine it by 
reading and evaluating just the first byte.


PS - a nomenclature proposal:

Serializing memory-specific structures like arrays into bytestreams for 
storage and transport, like we do with arrayEncode, is popular in many 
languages.  JSON is probably the most common serialized format after 
XML, and a binary variant named BSON is growing in use as the MongoDB 
that relies on it becomes ever more popular.

Exploring BSON in detail (Wikipedia's always a good start: 
<http://en.wikipedia.org/wiki/BSON> ), we can see some similarities in 
structure, and many similarities in usage patterns, with LiveCode's 
encoded arrays.

Given the popularity of JSON and BSON, and the value of adopting 
standard-sounding nomenclature when discussing a new tool with others, I 
sometimes refer to LiveCode's encoded arrays as LSON.

It's only slightly shorter than typing "encoded array", but hey, every 
little bit helps. :)

I feel the bigger benefit comes from sounding familiar.  In 
conversations with professional developers who are accustomed to *SON it 
helps convey that our community is also aware of other common 
conventions, and while LiveCode is in many ways completely different 
from other languages at least some things can be described in ways that 
make them more readily accepted by newcomers with deep experience using 
other systems.

Do you feel adopting "LSON" for encoded arrays is helpful or distracting?

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com