Consider S3 classes for strategy / metric objects

Aperta
  • Qualcosa non va?
#1,174 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
r
Ambito
backend-api-design

Direzione di ricerca

Inizia esaminando PR #1156 e i punti di ingresso filter_scores(), impute_missing_scores() e score(). Confronta i loro attuali controlli dei nomi formali e gli input di strategia/metrica, quindi considera in che modo validatori, costruttori, coercizione e metodi di stampa influirebbero sugli oggetti definiti dall’utente. Il lavoro è completo quando è stata raggiunta e documentata una decisione in merito al fatto che entrambi i concetti debbano diventare classi S3 e che la migrazione debba essere condivisa o incrementale.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Spun off from review of PR #1156.

In that PR we introduced a strategy-function-factory pattern for `filter_scores()` and `impute_missing_scores()`. @sbfnk raised (reasonably) that the entry functions accept any function and only check its formals, and suggested making the strategy an S3 class with type-checking.

We agreed in the PR discussion that this is a wider-scoped question:

  • The existing `metrics` argument in `score()` has the same shape (list of named functions) and is not an S3 class either.
  • If we adopt S3 here, we should decide whether to apply the same pattern to metrics for consistency.

What to decide:

  • Is there value in formalising "strategy" and "metric" as S3 classes with validators, or is the current formal-name check sufficient?
  • If yes, should both change together or is incremental migration OK?
  • What about user-defined strategies/metrics — constructors, coercion, print methods?

Not blocking PR #1156. Opening this for follow-up discussion.

This was opened by a bot. Please ping @seabbs for any questions.

Lingua principale
R
Stelle
65
Fork
24
Merge medio
1h 24m
PR unite (30g)
2

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di epiforecasts/scoringutils

Tutte le issue di epiforecasts/scoringutils

Issue simili

Altre issue su R

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.