Page 2 of 2

Re: turning on Unicode for arrayEncode/arrayDecode?

Posted: Wed May 28, 2014 7:36 pm
by FourthWorld
runrevali wrote:Hi all,

I have commented on the bug report, though it probably would have been better to do so here. So I'll effectively just copy & paste :-)

It is not necessary to remember which version this was added, the arrayEncode will preserve unicode for any stackfileversion >= 7.0. The only other solution available, I think, to enable unicode to "just work" in this case is to traverse the entire array prior to the encode, and check to see if it can be encoded losslessly in the legacy format; if not then it encodes in the new format.

The main disadvantage of this route of course is the extra time expense of the array traversal.
If this proves cost-prohibitive (please remember that many of us use array files on servers where CPU time is critical), I wouldn't mind if we opted to make the new format the default, allowing the older format with an argument flag (perhaps something like "plaintext").

The main thing is user simplicity, with a strong second being runtime performance.

If this means we have to update our apps to use array files made with the newer engine, that's really no different from supporting a new stack file format - as long as it's called out in bold red letters in the Release Notes, folks should be okay with it.

Re: turning on Unicode for arrayEncode/arrayDecode?

Posted: Wed May 28, 2014 8:35 pm
by DarScott
All of this has to bubble up to compatibility of documents and applications in our own applications.

Like this:

"ABC version 2.1 is fully compatible with version 2.0 and db files, however, though version 3.0 can read read-only version 2.0 db files, it creates smaller version 3.0 db files which are not compatible with ABC 2.0 and 2.1. ABC 3.0 includes an option to convert 2.0 db files to 3.0 db files."

I'm not saying that is a good upgrade style, I'm just saying that arrayEncode() can have an important impact on the upgrading of applications.

Re: turning on Unicode for arrayEncode/arrayDecode?

Posted: Wed May 28, 2014 8:47 pm
by FourthWorld
Forward compatibility is essential, common, expected, and supported here.

Backward compatibility is less commonly expected, but here is also supported with an optional argument for arrayEncode, similar to how LiveCode can ensure backward compatibility for stack files if the developer takes one small extra step to set the stackFileFormat before saving.