eh eh ci sarebbe da scrivere parecchio perche' non c'e' una regola unica.

Ti direi di stare attento ad usare mappe dapperttutto. Diventa facile perdere di vista cosa sta passando nella mappa che non e' di pertinenza della funzione corrente, e quindi rompere qualcosa di distante downstream che aveva bisogno di una certa chiave nella mappa.

In generale, direi di essere espliciti con gli argomenti finche' non ci sia una ragione per operare in altra maniera.

potrebbe essere una buona regola, se ci sono piu’ di 3 argomenti, considera se usare una mappa? quello che non mi piace e’ vedere una call ad una funzione ed usare l’ordine degli argomenti per vedere dove sono mappati

non so se mi sono spiegato bene 😄

Quindi cosa c'e' che non va qui sotto?

(defn myfn [a-num a-string a-vector])
(myfn 1 "a" [1 2])

qua niente pero’ qui si secondo me, c’e’ qualcosa che non va (defn [a b c d e f g])

anzi ti dico, a-num a-string a-vector sono anche nomi che mi fanno riconoscere cosa le cose sono guardando il tipo del parametro che sto passando

se non c’e’ il tipo, devo andare sulla call della funzione, emacs mi dice la sua definizione e poi devo mappare mentalmente i parametri

se invece ho: (f {:a "a" :b "b" :c "c"})

so gia’ nome del parametro e suo valore

cmq si concordo con te ovviamente che usare mappe DAPPERTUTTO non e’ buona cosa

perche’ poi ti perdi e non sai piu’ cosa contengono

Un altro problema nell'uso delle mappe è la mancanza di controllo della presenza di un parametro a compile time. Se ho (defn f [a b c] ...) e chiamo (f 1 2) se ne accorge subito...

Giusto, posso sempre usare pre conditions e controllare la presenza delle chiavi però no?

Che funzionano a runtime ovvio però se ho test su quelle funzioni io sono già contento

@UQ8KS67UL generalmente faccio come te, positional arguments fino a che sono pochi (3-4) e poi una mappa