Programmazione funzionale: Are Tuples è una valida alternativa ai Tipi?

Question

Programmazione funzionale: Are Tuples è una valida alternativa ai Tipi?

#1 da (9 voti)
#2 da (-1 voti)

4

Qualche tempo fa ho deciso di imparare Haskell per aiutare ad apprendere più idee "pure funzionali" che potrei applicare a F #. A prima vista sembra che non ci siano tipi reali in Haskell come quelli che ha F #. Sto bene così ho voluto trovare un modo per rimuovermi dal design ibrido OO / Functional che ho usato in F # e provare davvero a diventare senza classi e sviluppare veramente un design incentrato sulle funzioni. La prima cosa che mi è venuta in mente quando ho usato Haskell era di passare semplicemente le tuple in giro perché possono contenere informazioni in coppie di valori chiave molto simili ai linguaggi dinamici ma non hanno la sintassi del costruttore come i tipi F #.

Ad esempio in F #:

type DatabaseWorkValueItem(firstItem, secondItem, thirdItem) =
  member public x.FirstItem = firstItem
  member public x.SecondItem = secondItem
  member public x.ThirdItem = thirdItem

E questo sarebbe nel mio nuovo design proposto:

module DatabaseWorkValueItem =

  let firstItem (item, _, _) = item
  let secondItem (_,item, _) = item
  let thirdItem (_,_, item) = item

  --Replace constructor with method
  let CreateValueItem (parameter:String, value:Object, sqlType:SqlDbType) =
    (parameter, value, sqlType)

  --Replace properties with more methods
  let GetDataType (item :(String *Object * SqlDbType)) = 
    thirdItem item

  let GetParameter (item :(String *Object * SqlDbType)) = 
    firstItem item

  let GetValue (item :(String *Object * SqlDbType)) = 
    secondItem item

Entrambi hanno la stessa idea. Si crea una classe come Tipo con proprietà impostate su costruzione e l'altra utilizza tutte le funzioni per creare e leggere una tupla.

La domanda è: sono pazzo a preoccuparmi di questo? Anche se mi rendo conto che F # ha la comodità di saltare tra due paradigmi, non posso fare a meno di pensare che sia una coperta constrongvole per

functional-programming

posta Programmin Tool 09.01.2012 - 17:48

fonte

2 risposte

-1

I generici esistono perché rendono facile la programmazione della vita. La tua domanda è simile a chiedere se l'utilizzo di un elenco che accetta tipi di interi nel suo argomento generico è in qualche modo meno sicuro rispetto alla progettazione di un elenco chiamato IntList che è codificato per accettare solo Ints.

In Java a C #, normalmente c'è un oggetto punto geometrico chiamato Point3D con parametri float x, y, z. Ma dovrebbe essere chiaro che una tupla di 3 tipi di float è funzionalmente equivalente a Point3D.

I programmi di stile a passaggio continuo consentono di restituire l'output in più di una variabile. I programmi di stile diretto consentono di restituire l'output in una sola variabile. Le tuple sono un modo rapido che consente di restituire più di un output in una funzione e impediscono alle classi di posta indesiderata di inquinare la libreria quando non è necessario gestirli.

risposta data 03.05.2012 - 00:02

fonte

Leggi altre domande sui tag functional-programming

È 'processo di debito' un termine con cui le persone lavorano Accedi all'applicazione all'avvio

score 9 · Accepted Answer

Non so cosa ti fa pensare che Haskell non abbia tipi reali o che l'utilizzo di tipi diversi sia in qualche modo contro il concetto di programmazione funzionale. Passare attorno a tuple invece che a tipi più significativi è una pessima idea sia in F # che in Haskell poiché diminuisce notevolmente la sicurezza del tipo che le lingue tipizzate staticamente come Haskell e F # offrono.

La sicurezza del tipo statico è un concetto molto importante nei linguaggi di programmazione funzionale tipizzati staticamente (ancor più che nei linguaggi OO tipizzati staticamente, direi) e il codice che utilizza solo le tuple non sarebbe assolutamente idiomatico in nessun linguaggio del genere. / p>

Ad esempio, considera un'applicazione che rappresenta la struttura di un'università. Questa applicazione può avere tipi per rappresentare studenti e classi (tra le altre cose, ovviamente). Diciamo che uno studente ha un nome e un'età e una classe ha un nome e un numero di partecipanti. Entrambi possono essere rappresentati come tuple (String, Int) . Tuttavia, se lo fai, qualsiasi funzione che accetta uno studente come argomento accetta anche una classe invece senza causare un errore di compilazione perché tu rappresenti entrambi usando lo stesso tipo. Se definisci tipi separati per studenti e classi che non si verificano.