@Developers: Functions to Avoid...
R_J
Admin
Don't use c() and t() because they will be deprecated:
https://github.com/vanilla/vanilla/issues/7688
https://github.com/vanilla/vanilla/issues/7687
Instead use the longer form Gdn::config() and Gdn::translate().
Something which might not been known, but has been said long before: avoiding val() is a good idea, too. Not because it will be deprecated (soon :shrug:), but simply because it is not needed oftentimes. If you now the type of the variable simply use the correct code to get the arrays element/objects property. Right now val() is purged out of Vanilla from all the places where it is possible:
https://github.com/vanilla/vanilla/pull/7689
By the way: I don't know such things because someone tells me, I simply follow what's going on on the GitHub repo. If you want to stay up to date, I recommend watching the repo 
Comments
We recently hired a new lead developer who has been working on optimizing our framework. Eliminating the morass of redundant function calls created by those shortcuts was an easy place to start. We don't plan to eliminate them for a long while, but we're removing thousands of function calls from core by eschewing them.
The idea that removing a function call that calls the singleton method anyway, would provide any significant performance boost make no sense, so not sure what is meant by 'optimising'. There could be other reasons such as reducing and rationalising the code base to focus on core objectives. Fair enough.
@RJ I agree about val it is a convenience method that I'm guilty of using a little too much. Bad habit.
I'm all for improvement, however the lack of engagement with addon developers is just goign to mean they less inclined to maintain them, they will just move on and more ad more of them will be broken. Very few of us have time to completely re-factor them every new release. Breaking changes may have to be made, but sometime breaking changes aren't made to improve anything and are just code idealism, and that can be frustrating.
Perhaps it is to make it easier for the core team and easier for developers, that is fine, but unless this is communicated what is required, addon developer aren't going respond in time, if at all. Right now there is no relationship between core releases and addon releases. Merely the implication exists.
Also if the core team are goign to make sacrifices for the greater good then addon developer should be able to too. I want to cut down on what I wish to support, becuase they are either obsolete, my time is better focus on the ones that matter.
grep is your friend.
"We don't plan to eliminate them for a long while" sounds like the opposite of a breaking change, no?
Also... you could just copy them to your addon, right? The idea that removing them from core (one day) means a total refactor of something is a bit disingenuous when there's a copy/paste workaround.
Do you have a better way of communicating that than adding deprecation notices many releases ahead of any intended removal?
Finally, I'll point out that @R_J pointed out the deprecation less than 2 weeks after we barely started it, and before we've even finished fully removing a single one of them from core. So the idea that we aren't giving enough notice seems like a stretch, too.
We profiled our function calls and discovered (as I recall) more than 6,000 calls to
val()alone. Per page load.While I generally agree that removing aliases aren't a huge gain, it's a pretty easy way to remove tens of thousands of function calls in Vanilla. It also removes a level of abstraction, makes traces a few less lines long, and makes things clearer for newer developers.
Removing 10,000 or more redundant function calls per page times millions of page views per day is nothing to sneeze at.
I am not concerned about the advanced deprecation because they are, as Linc wrote, way in advance.
There was a mention in this discussion about developers support. That is a concern of minerelated to the active plugin library and whether they are slowly being de-supported by developers. The download counts may reflect historic numbers and it is still hard to know which plugins work or not.
I recently uploaded a plugin (that needs cleanup work, but that's another issue) and see a tiny download count. Sure, it may reflect a community disinterest of the specific functionality, but I wonder whether in an active community people wouldn't download plugins just to try them out. If so, the small download count may reflect very little activity, which is a concern.
It may not be a bad idea for that code to be audited to make sure the counters are working correctly. No one is explicitly in charge of maintenance for the community repo and it tends to get neglected until obvious problems arise.
Just to clarify, I don't claim a bug in the counter, just that the number reflects downloads from all versions of the plugin so a high count nay not reflect current interest.
I think the plugin directory should be of interest to Vanilla. I assume there's a well maintained cloud version for paying customers. Can that be used for the open plugin directory?
@Linc Yes it is true that cleaning up the code is a good thing. Regards breaking changes, there have been various examples of that I have seen over the years for example providing a new method that call the original method but changing round the parameters in the original method so it breaks, html emails were also breaking change, it messed up text and mixed content emails (due to hard coded string concatenation), which can only be properly resolved by overriding the template class. That affects more than just developers.
I don't think backward computability is particularly realistic for a large addon where we are at with the core, that is ok you have to change. IMO addons should be tied to major releases. Therefore then can select the version when they search for them. It will reduce the results that come up, but that is not bad thing. There is re-factoring goign on, so if you want to reduce the unrealistic expectation both the core and developers will choose what to support, and if they choose to then they will create an update to match the release. There may need to be some buffer period so there is enough time.
The main point is depreciation warnings aren't going cut it, that only applies only to methods not methodologies. If you think that addon are a selling point then developer need to be better pepped for releases, what changes will affect them.
grep is your friend.
Our cloud forums come with a curated list of addons pre-installed, so there's no cloud equivalent to the directory here.