Mark Waddingham wrote:
> The problem with fixing them is that in most cases people will have
> coded around them - and thus changing the behavior without some sort
> of compatibility mechanism would break a great many lines of script.
IMO that's not your concern. Fixing oddities in the language is good,
and when it requires us to remove strange workarounds that should be a
welcome exercise.
The key is twofold:
1. Discussion with developers, such as this one and in the bug reports,
to make sure the change is really the right thing to do. Once in a
while (though not often) seemingly odd behavior may actually make sense.
Good to double-check.
2. When a change is made that may affect existing code, CALL IT OUT
CLEARLY IN THE RELEASE NOTES, perhaps in all-caps since that tends to be
sufficiently alarming to get people to read them. Maybe also in bold
and red. Many still won't read the Release Notes and just gripe later
anyway, but over time they'll learn how useful the Release Notes are.
Besides, losses of backward compatibility have been very, very rare, so
this is a minor concern in the grand scheme of things.
As much as we appreciate LC's unusually high regard for backward
compatibility, it is unusual and sometimes risks holding the language
back from being cleaner and more efficient. If it's determined that an
inconsistency can be removed where the only downside is having to remove
funky workarounds, go for it.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
[email protected] http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
