best/fastest way to tell if a field contains unicode text?

Fraser Gordon fraser.gordon at runrev.com
Wed Mar 26 13:03:08 EDT 2014


On 26 Mar 2014, at 15:37, Geoff Canyon <gcanyon at gmail.com> wrote:

> 
> "somebody, somewhere, might be depending on the fact that it interprets the
> number modulo 256"

We've already had a bug report against 7.0 because it wasn't doing that in certain cases. 

The problem with making non-compatible changes to existing APIs is that changing things to work against the new API isn't a one-time cost. If you take LiveCode itself as an example, there are a number of run-time checks where things are done differently depending on the operating system version because something broke when a new version of the OS was released. Sometimes, we are lucky and the fix works on old versions too but (more often) it doesn't so both code paths have to remain until support is dropped for the older version.

> 
> My point is that we will *all* suffer with poor, confusing syntax,
> *forever*, so that hypothetical person doesn't have to fix their use of
> numToChar.

Backwards compatibility in LiveCode only needs to be sustained until Open Language: at that point, the core language will be cleaned up so that these legacy issues can be forgotten (though the old language will hang around as a backwards-compatibility mode for existing scripts but can be ignored when writing new scripts).

> 
> One of the main advantages of Livecode is the natural syntax. Sacrificing
> that to backwards compatibility is a poor trade-off.
> 


I agree that clean syntax is better but there are limits to what we can do - it can be very discouraging when you upgrade to the latest-and-greatest version of some software and suddenly something doesn't work (I get that feeling when having to switch between the various versions of Xcode that we use!).

"numToChar" and "charToNum" are unsound concepts anyway - imagine you have the sequence of Unicode "characters" (really codepoints) {"e", combining-accute} - these will display as a single grapheme "é" which means that in the LiveCode language they are one character. However, there are two codepoints - how do you map that to a single number? This may seem esoteric, but on MacOS X, accented characters in file names are returned in such a form. Either charToNum will have to not match what "char" means in LiveCode or it will have to fail on what is a relatively common occurrence. Thus, doing the wrong, backwards-compatible thing seemed a better choice than doing a new wrong thing.

Backwards compatibility is a trade-off and in this case the upsides to breaking something just weren't enough. At least it isn't forever...

Regards,
Fraser





More information about the use-livecode mailing list