Discussion: Procedures for managing Overwrite methods in mixins about sponge HOT 7 CLOSED

@Zidane after dealing with a few overwrite rewrites the last couple of days, I feel that we need to heavily start enforcing the idea at least to either include (commented out) vanilla code and the javadoc for @author and @reason. Mixin is already complaining about all of the current overwrites for the missing javadocs.

from sponge.

Just to make clear, this was Mumfrey's original post so direct inquiries to him.

from sponge.

I actually forgot about this, I started writing it up but got super frustrated with the crappy not-quite-as-flexible-as-markdown markup that the docs project uses. I will finish writing up when I get a minute.

from sponge.

This looks good to me.

from sponge.

I believe we've taken a deviation from this original thought where the old code isn't directly copied as comments, but rather just eliminated if overwritten. There are approximately 90+ @Overwrites in the current implementation, so re-evaluating all of them to work would not sufficiently suffice unless we spent the time now to re-analyze the original overwrites and re-document and update with all of the previous code that was excluded and re-added strictly as comments.

from sponge.

So this is now policy right, and can be closed?

from sponge.

I just think there's no official guideline we can point to for implementation, but yes, at this point we do fooollow our unofficial guidelines about overwrites.

from sponge.