On 26 Mar 2014, at 15:37, Geoff Canyon <gcan...@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
_______________________________________________
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
