The current way to advise the user of deprecated method calls is rude: we changed something; the user did nothing wrong; but, particularly if the method call is in a long loop, the user may get flooded with repetitive warnings in the post window (and, if it’s a time-sensitive loop, the user may be unable to ignore the performance penalty of the repeated posts).
Instead, what if we provide scripts to search for keywords that may be deprecated? This is easy in unixy platforms; I’m not sure about Windows.
There may even be ways to report search results proactively (run a search when opening a file in the IDE, say, though automatically checking quark .sc files isn’t so straightforward).
Thinking of this particularly because were discussing deprecation of Condition. That is likely to bite a lot of users in unexpected places. It would be worth considering how to have a gentler user experience here.
Yes, this is totally a problem. A really simple solution for this is log throttling. A mechanism attached to the particular log line you want to limit checks how frequently the message is being logged, and suppresses too-frequent logging. This is easy to implement and we could probably just make it part of the deprecated error class.
I think you suggested somewhere also a script that tries to automatically find and/or replace deprecated features. This would be much harder to do with the tools we currently have available, in a general way, but is definitely worth exploring in my opinion. Have you tried mocking anything up along those lines, to see how well it would work?
I think, because of runtime dispatch, it isn’t possible to do this automatically. But I can see in my head a way to use Document’s initAction to scan a file when it’s opened… but I have 6 hours of lessons today, unlikely I can sketch it out just now.