HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

@Developers: Functions to Avoid...

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 :wink:

Comments

  • LincLinc Detroit Admin

    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.

  • LincLinc Detroit Admin
    edited August 2018

    @x00 said:
    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.

    "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.

    but unless this is communicated what is required, addon developer aren't going respond in time, if at all.

    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.

  • LincLinc Detroit Admin

    @x00 said:
    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'.

    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.

  • rbrahmsonrbrahmson "You may say I'm a dreamer / But I'm not the only one" NY ✭✭✭

    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.

  • LincLinc Detroit Admin

    @rbrahmson said:
    I recently uploaded a plugin (that needs cleanup work, but that's another issue) and see a tiny download count.

    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.

  • rbrahmsonrbrahmson "You may say I'm a dreamer / But I'm not the only one" NY ✭✭✭

    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.

  • LincLinc Detroit Admin

    @rbrahmson said:
    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?

    Our cloud forums come with a curated list of addons pre-installed, so there's no cloud equivalent to the directory here.

Sign In or Register to comment.