Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Prevent accidental proc overwriting, proc signature overloads

Offen
#1,213 12 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
java
Bereich
compilers

Rechercherichtung

Beginne damit, die beiden Vorschläge und die Diskussion über die Semantik von final, overwritable und overwrites zu lesen. Das Issue nennt keine Dateien, Tests oder Einstiegspunkte, und der Abschluss hängt davon ab, das Verhalten der Schlüsselwörter festzulegen, die Signaturübereinstimmung zu bewerten und vor der Implementierung Nutzerforschung oder Telemetrie durchzuführen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

discussion wanted feature request

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

Vorherrschende Sprache
Java
Sterne
128
Forks
70
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus EngineHub/CommandHelper

Alle Issues in EngineHub/CommandHelper

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.