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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
