Scala: la funzione di selezione ritorno Opzione rispetto funzione parziale

Question

Sono un principiante Scala relativa e vorrebbe qualche consiglio su come procedere su un'implementazione che sembra come esso può essere fatto sia con una funzione che restituisce Opzione o con funzione parziale. Ho letto tutti i relativi messaggi sono riuscito a trovare (vedi fondo questione), ma questi sembrano coinvolgere i dettagli tecnici relativi allo sfruttamento funzione parziale o convertire l'uno all'altro; Sto cercando una risposta del tipo "se le circostanze sono X, Y, Z, quindi utilizzare un altro B, ma prendere in considerazione anche C".

Il mio caso ad esempio l'uso è un percorso di ricerca tra le posizioni utilizzando una libreria di cercatori di percorso. Dicono che le posizioni sono di tipo L, un percorso è stato di tipo P e il percorso risultato della ricerca desiderato sarebbe un Iterable[P]. Il risultato della ricerca cerotto deve essere assemblato chiedendo tutti i cercatori di percorso (in qualcosa di simile a Google maps questi potrebbero essere biciclette, auto, a piedi, metropolitana, ecc) per i loro suggerimenti di percorso, che può o non può essere definita per un particolare start / posizione finale coppia.

Sembra che ci siano due modi per andare su questo:

(a) definire un cercatore di percorso come f: (L,L) => Option[P] e quindi ottenere il risultato tramite qualcosa come finders.map( _.apply(l1,l2) ).filter( _.isDefined ).map( _.get )

(b) definire un cercatore di percorso come f: PartialFunction[(L,L),P] and then get the result via something likefinders.filter (_.isDefined ((L1, L2))) .map (_.apply ((L1, L2))) `

Sembra usando una funzione che restituisce Option[P] eviterebbe doppia valutazione dei risultati, quindi per un calcolo costoso puo essere preferibile meno uno memorizza nella cache i risultati. Sembra anche utilizzando Option si può avere una firma ingresso arbitrario, mentre PartialFunction prevede un singolo argomento. Ma io sono particolarmente interessato a sentire da qualcuno con esperienza pratica circa meno immediato, più considerazioni "grande quadro", come ad esempio l'interazione con la libreria Scala. Sarebbe utilizzando un PartialFunction avere vantaggi significativi nel rendere disponibili alcuni metodi dell'API collezioni che potrebbe pagare in altri modi? Sarebbe tale codice in genere essere più conciso?

Related ma diverse domande:

• Inversa di metodo di sollevamento di funzione parziale
• è la progettazione funzione parziale inefficiente?
• Come convertire X => Opzione [R] per funzione parziale [ X, R]
• C'è un modo migliore di sollevamento una funzione parziale a Scala?
• costosa calcolo verificano sia TestDefinito e applicare di una funzione parziale

Answer 1

Ci si sente come Option potrebbe misura il vostro caso d'uso migliore.

La mia interpretazione è che funzioni parziali funzionano bene per essere combinati su campi di ingresso. Quindi, se f è definito su (SanDiego,Irvine) e g è definita su (Paris,London) allora si può ottenere una funzione che si definisce il (SanDiego,Irvine) di ingresso combinato e (Paris,London) facendo f orElse g.

Ma nel tuo caso a quanto pare, le cose accadono per una data tupla posizione (l1,l2) e poi fare un po 'di lavoro ...

Se vi trovate a scrivere un sacco di {case (L,M) => ... case (P,Q) => ...} allora può essere il segno che funzioni parziali sono una migliore vestibilità.

In caso contrario opzioni funzionano bene con il resto delle collezioni e può essere utilizzato in questo modo al posto del tuo (a) proposta:

val processedPaths = for {
  f <- finders
  p <- f(l1, l2)
} yield process(p)

All'interno della per la comprensione p viene sollevato in un Traversable, in modo che non hanno nemmeno bisogno di chiamare filter, isDefined o get di saltare i cercatori, senza risultati.

Answer 2

Non è tutto quello che sa, ma dal momento che 2,8 Scala ha un metodo collect definito su di essa la collezioni. collect è simile a filter, ma prende una funzione parziale e ha la semantica si descrive.