On 2015-10-26 15:51, Rick Harrison wrote:
Whenever one deprecates code, it destroys someone’s code somewhere.
Don’t do it.
Indeed, we have tried and do continue to try our very best not to break
people's code as the platform evolves (even though this is a huge
constraint to put on a programming environment which evolved from
something born in the late 1980's - it makes the assumption that all
decisions taken then and up until were correct then and correct relative
to any future consequence and thus have no forward consequences - which
is definitely not the case).
However, I'm not going to commit us to never deprecating things - we do
and will continue to do so as needed. Deprecated features will continue
to work for as long as it is feasible to do so.
A work around is to let all previous versions work, and put the final
winning
candidate into the dictionary, the others will no longer appear in the
documentation. This solves the problem with the least disruption as it
doesn’t break anyone’s code, but helps to streamline the desired future
syntax for the language.
The problem here is that you are assuming it is possible for 'all
previous versions to work' from now until some arbitrary point in the
future. This just isn't the case - code ages and computer technology
continual renews.
For example, the 'liveResizing' property no longer does anything. Why?
Because Cocoa has no facility to turn liveResizing off.
Similarly, things like the 'pixmapId' properties and such used to allow
you to do really funky things on certain platforms which it was not
possible to continue to make work when we brought the graphics
capabilities up to scratch with other environments in 2.7. (Fortunately,
long before these 'funky things' stopped working we provided a much
better way to have the same effect - i.e. export/import snapshot from
object).
In terms of syntax / synonym related suggestions - then the situation is
much easier. We might deprecate some, just to make it clear what the
'preferred' form is and to discourage further usage. We would never
remove them until such a point that we do have a suitable migration tool
/ method of expressing them which means people can choose to use them,
or not, depending on their own personal preference.
In terms of current functionality (from a semantics point of view) there
are a growing list of 'anomalies' in the bug database which are things
which really aren't 'correct' at the moment (and never have been). It
would be better for all new code and new users if they were not ladened
with the baggage of those things being how they currently are. However,
again, we aren't going to change that functionality until we can
implement a compatibility mechanism meaning you don't have to update old
code.
I suspect the environment you have been bitten by in the past was one
which was hugely monolithic in terms of implementation. They probably
redid the internals with little regard for backwards compatibility
(because it wasn't a viable business avenue for them to be concerned
about it - or they simply did not know how to) to reduce the engineering
burden and to breath new life into it in the modern era (and thus
continue to be viable).
The difference in LiveCode's case is that whilst the entire refactoring
project, widgets and (eventually) Open Language is about turning
something monolithic and hugely constrained into something modular and
open, we are trying to do it in such a way that will ensure existing
code will continue to run.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
