[Python] Dubbi su hash e set

[enrico franchi]

2008/5/5 Pietro Battiston <toobaz a email.it>:

>  Come vuoi, allora è questione di esperienza con programmazione agli
>  oggetti, per me pari son.

E allora segui il mio consiglio. :)

>  Non lo farò per una classe con 3 metodi, ma se anche lo volessi fare non
>  mi sembra un argomento a favore del contenimento e contro l'ereditarietà.

Ribadisco, la politica è: a meno che non sei assolutamente certo che
ereditare sia la cosa giusta, probabilmente è la cosa sbagliata.


>  Pazienza per il mini-corso, ma un indizio del perché ti sia così chiaro
>  che la mia relazione è del tipo has-a?!
>  A me sembra di avere "deciso", più che "verificato", che la relazione è
>  del tipo is-a, perché mi sta più comodo così.

Scusa, ma non capisco per quale motivo un "vertice" dovrebbe *essere*
un insieme.
Non mi è nemmeno chiaro il perchè dovrebbe essere implementato in
termini di insieme,
ma questo suppongo dipenda che non ho presente il tuo problema specifico.

Invece non mi risulta chiaro per quale motivo, appunto, un vertice
*sia* un insieme.


>  Sto "chiedendo guai" nel senso che non sapevo proprio quali erano i
>  requisiti per essere "set-compliant", ma ora che so come evitare danni
>  con gli unici due metodi che dovevo sovrascrivere...

Hai guardato il mio codice di esempio?

Il problema è che devi avere idea *precisa* sul funzionamento della
classe da cui erediti, di *tutto*, anche di quello che non usi.
Altrimenti puoi trovare bachi inaspettati.

>  In cui parla proprio e solo di eredità... ?! E dice ovviamente di
>  evitare la cavolata che facevo quando ho scritto la prima mail, ma che
>  ora mi sembra di aver risolto... ma di per sé, il principio "non fare
>  arrabbiare le classi da cui erediti" mi sembra anche piuttosto scontato...

La cosa che ti dice (leggendolo) è anche che devi stare *molto*
attento a rispettare i contratti impliciti delle tue classi padre.
Per cui, di fatto, ti conviene farlo solo con *moltissima* attenzione.
Il che vuole dire, di base, non farlo.

>  Qui mi sa che mi mancano un po' di basi per capire... in Python non è
>  //tutto// open (a parte casomai la sovrascrittura dei metodi di tipi e
>  classi builtin, ma mi sembra il minimo)?! Insomma, da quel pochissimo
>  che so di Java, e forse in C++, so che ci sono classi pubbliche e
>  private... in Python capisco che ci siano "calde raccomandazioni" per
>  chi usa un certo modulo, ma alla fine decidere "cosa è open" si riflette
>  tutt'al più nella documentazione, no?!

No. E' una questione "filosofica". Cioè è vero che in Python posso
prendere una classe e patcharla a runtime,
ma qui il discorso è soprattutto evolutivo.

Cioè tu scrivi un modulo/classe/whatever. Se lo scrivi bene, quel
modulo sarà facilmente estendibile
in un secondo momento (quando le esigenze cambieranno) e questo
avverrà tipicamente senza mettere
troppo mano al codice esistente. Questa è una volgarizzazione
terribile, ma dovrebbe rendere bene la faccenda.

Chiaro che in Python sei libero pure di monkey-patchare il mondo, ma
questo non vuole dire che sia una buona idea
farlo. Tipicamente se ho ben scritto il modulo, non verrà nemmeno idea
di farlo, perchè mi basterà estenderlo nei
modi che mi interessano senza *doverlo* modificare (certo, volendo, posso).

Poi ovviamente ci sono buoni motivi anche per modificarlo: il modulo
era scritto male, dobbiamo fare cose veramente poco prevedibili

-- 
-enrico