EngineHub / EngineHub/CommandHelper

Prevent accidental proc overwriting, proc signature overloads

Open
#1,213 12 comments 0 reactions 0 assignees View on GitHub
discussion wanted feature request
Dominant language
Java
Stars
128
Forks
70
PR merge metrics
No merged PRs in 30d

Description

A discussion came up about being able to overwrite procs. There are definitely good use cases for being able to overwrite procs, but the discussion was that perhaps this is not a good thing by default/generally.

A number of proposals were offered, summarized here. For clarity, the term "final" is taken to mean that a proc cannot be overwritten, whether or not there is a keyword `final` involved.

1. No change in existing behavior, but a new keyword `final` is introduced, and when applied to procs, prevents them from being overwritten elsewhere.
- Pros: No user code has to change. The implementation is simpler, and doesn't require a phase in period.
- Cons: If a user is accidentally overwriting a proc when they didn't mean to, this feature will not benefit them.
2. Add overwrites/overwritable/overwrite keyword(s). This changes existing behavior, so that all procs are final by default, but procs that are marked with some combination of either/both `overwrites` and/or `overwritable` are allowed to be overwritten.
- Pros: It's impossible for users to miss accidental overwrites, as this is much stricter.
- Cons: Behavior change, requires users to change code and requires a phase in period. It seems unlikely that this would be a widespread problem, but in general this would require a phase in period, and we should create telemetry on this to count how many people are affected, and the magnitude that they are affected before making this functionality visible to users at all.

For option 2, there is still a need to determine the specific keywords that are used. Do you put the `overwritable` keyword on the "master" proc, and the `overwrites` keyword on the sub-proc? Or do you just have a single keyword `overwrite` which you tag on all procs that are intended on being overwritten and the procs that overwrite them? This is a minor discussion that needs to happen still, but does not materially change the overall decision.

Another discussion is to also perform signature matching on non-final procs. So redefining a proc (which is either implicitly or explicitly overwritable) with a new signature should be disallowed. I generally support this, but this is a different decision and implementation. This may however prevent valid use case, so further user research needs to be done to provide input to this decision.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.