Uso corretto dei typeclass

Solitamente in questo tipo di situazione, devi semplicemente creare un semplice tipo di dati o forse un record per aggregare i diversi campi:

data Displayable = Displayable Picture (Float,Float) (Float,Float) Float

Le classi di tipo sono per quando hai bisogno di invio polimorfico a molte implementazioni della stessa funzione. Questo non è certamente il caso per scala e posizione, per cui avrai solo un'implementazione. Le dimensioni possono essere calcolate in modi diversi, ad esempio in base alle dimensioni naturali di una bitmap, ma tali differenze possono quasi certamente essere prese in considerazione al momento della costruzione.

Potresti avere un caso per rendere toPicture parte di una classe di tipi, ma questo probabilmente può essere gestito principalmente anche in fase di costruzione, quindi avere una funzione che aggiunge le trasformazioni appropriate su una base Picture solo prima di renderlo.

Un'altra possibile struttura dati potrebbe essere un Picture e un elenco di funzioni di trasformazione da applicare ad esso:

data Displayable = Displayable Picture [Picture -> Picture]

Ciò semplifica l'aggiunta di nuovi tipi di trasformazioni, come rotazioni o persino combinazioni complesse di trasformazioni, ma rende più difficile eseguire operazioni come ripristinare la scala sul valore predefinito. Forse potresti aggiungere una descrizione di String per ogni trasformazione. Qual è il migliore dipenderà dalla tua applicazione. Il mio punto di includere questo esempio è mostrare che l'utilizzo di campi funzione può spesso impedirti di ricorrere a una classe di caratteri.

Non è che le classi tipo non siano utili. Lontano da esso. È solo che le situazioni in cui la creazione di una nuova è la soluzione migliore sono relativamente rare. Quando hai bisogno di crearli, in genere sono molto piccoli e quasi mai cambiano. Se stai pensando che potresti dover aggiungere una funzione a una classe di caratteri in un secondo momento, dovresti farti pensare due volte a usarne una.

Va bene avere un sacco di funzioni per manipolare il tipo di dati in modi più facili da programmare, ma si vuole che siano al di fuori delle classi di tipi, se possibile. Ogni volta che aggiungi una funzione a una classe di caratteri, devi aggiungerla a ogni singola istanza.

Di solito è una buona idea evitare classi di tipi a meno che non fornisca un beneficio specifico che non può essere ottenuto con altri mezzi. Questo articolo fornisce una visione un po 'estrema su questo, quindi prendilo con una grana di sale, ma può aiutarti a capire perché le classi di tipi possono essere problematiche.

Le classi di tipi di problemi principali operano su livello di tipo , il che significa che provare a fare cose complicate con le classi di tipi richiede in genere una pletora di estensioni Haskell e talvolta persino impossibile. al contrario, operare su livello di livello è molto più semplice e non è necessario combattere con il correttore di tipi e digitare regolarmente il processo di inferenza.

I getter e i setter hanno il loro posto in Haskell, ma sono principalmente per mantenere la compatibilità dell'interfaccia e usarli eccessivamente causerà un sacco di errori. Per semplici strutture di dati interne, potrebbero non valerne la pena.

Nel tuo esempio, sarebbe molto più semplice implementare Displayable come un tipo di dati ordinario (come mostrato nell'esempio di Karl Bielefeldt), con l'ulteriore vantaggio di poter memorizzare tutto Displayables in un contenitore senza estensioni funky come ExistentialTypes . Inoltre, puoi utilizzare la corrispondenza dei pattern (o la sintassi del record) per decostruire il tuo Displayables .

Sulla questione delle definizioni predefinite, dovrebbero essere usate con cautela. Inoltre, è probabilmente una cattiva idea scrivere le impostazioni predefinite che non funzionano su ogni istanza . Non è una linea guida rigorosa, ma aiuta davvero a prevenire errori stupidi come dimenticare di scrivere una funzione per un'istanza: senza valori predefiniti, se si dimentica qualcosa, il compilatore ti avviserà o, nel peggiore dei casi, causerà un errore di runtime; non è così se è impostato come predefinito, e se il comportamento predefinito è sbagliato , il tuo programma potrebbe finire in modo subdolo.

Addendum: un "record of methods" (o "instance dictionary" come viene spesso chiamato) è in realtà ciò che Haskell usa per implementare classi di tipi sotto il tappeto. Tale approccio sarebbe qualcosa di simile:

data Displayable d = Displayable
  { display   :: d
  , toPicture :: d -> Picture
  , getDims   :: d -> (Float, Float)
  , getPos    :: d -> (Float, Float)
  , getScale  :: d -> Float
  , setDims   :: (Float,Float) -> d -> d
  , setPos    :: (Float,Float) -> d -> d
  , setScale  :: Float -> d -> d
  }

Qualsiasi classe di tipo può essere trasformata in questo modulo: questa una traduzione letterale della classe tipo nella tua domanda. Probabilmente però non vuoi usare in questo esatto modulo: è meglio se riesci a capire quali parti di Displayable devono essere veramente astratte e quali parti puoi rendere concrete . Troppa flessibilità può rendere il codice più complesso di quanto non sia necessario.