Open gabizou opened 7 years ago
The best way to handle the LVT would be to define a Javadoc format, for example:
/**
* @lvt boolean flag2, isCriticalAttack, Whether critical particles will spawn and of course, multiply the output damage
*/
Basically the same thing you have in your example, just well-defined. This is helpful for me since these Javadoc parameters are parsed out in the Psi structure, so it would be much easier for me to handle them.
With Mixins, we all can write
@Overwrite
methods all day, but when transferring code from one version to another (for Minecraft), there are some overwrites that are immensely important that we get right. This was spoken about with @DemonWav and @Mumfrey a few days ago where you could open a diff viewer of what your overwrite is (even use VCS diff viewers) applying in changes on top of the original method. To top it off, it would be amazing that if you wanted to overwrite a method, you could go through and perform an LVT translation table for what various local variables are originally called (usually float1 or boolean1 etc.) to give them proper names.An example of an
@Overwrite
that would be a good test is the following from SpongeCommon:Now, the obvious part of this overwrite is that I hand wrote the LVT as necessary. Not all the local variables were useful to rename as that would generate more clutter.
A more formal checklist of features that this would include:
Thoughts?