There are a raft of changes (some quite significant) which would improve LiveCode Script no-end (whether it be from the point of view of new people coming to the platform, or making it possible for existing people to write better and more robust programs), but come at a hefty risk of breaking existing scripts. Here are a few:
- setProp / getProp handlers always firing regardless of the state of message locking (lock/unlock messages)
- whether an array's keys are considered case-sensitive should be a property of the array, and not based on a local property
- arrays really should throw an error when attempting to convert to a string
- revXML and revDB functions should be returning (abstract) strings and not raw data
- 'the result' not being a global variable and being local to handlers
- error handling being unified as exceptions
Some sort of mechanism which means that existing scripts can run in a 'compatibility mode' to allow their authors to take advantage of new features immediately, whilst updating their existing scripts over time would be the ideal here.
One idea is to introduce an (inheritable) 'scriptVersion' property of objects. This would be a monotonically increasing integer, at each increase a number of semantics would change meaning that you would need to review the scripts of the objects for which you needed to increase its value.
Another idea is to introduce an (ever-increasing!) collection of boolean flags which could be set on objects to describe the specific semantics to which the script has been written.
On the one hand, a single scriptVersion might be too coarse. It is easy to imagine that some systems might be stuck at scriptVersion X for a long time because scriptVersions X+n all contain changes in semantics which would take a long time to patch code to support.
On the other hand, a huge array of boolean flags might be incredibly confusing (and produce an internal engine maintenance nightmare).
Perhaps there's something in between (LCB modules will eventually be intrinsically versioned - the author the module if he/she do their job correctly will be able to support API changes for as many version of the module as they wish ensuring that a program which uses version N of a module will continue to function even if version N+M is the current one).
Or perhaps we should all just 'swallow hard' and realize that it is untenable for LiveCode to continue support script semantics (many of which grew organically and were defined more than a decade ago) in a world which changes as fast as the computer industry does and all take the hit in terms of the work required to keep up to date with the latest and greatest versions and features. (Its the mixed mode here which I'm talking about - allowing existing scripts to 'forever' work alongside scripts which use much newer and perhaps substantially different functionality and semantics).
Anyway, just thought I'd post this to see what people think...