[Python] Dubbi su hash e set

[Pietro Battiston]

enrico franchi ha scritto:
> On Mon, May 5, 2008 at 9:20 AM, Pietro Battiston <toobaz a email.it> wrote:
>   
>> Pietro Battiston ha scritto:
>>  > enrico franchi ha scritto:
>>
>>
>>     
>>>> On Sun, May 4, 2008 at 7:20 PM, Pietro Battiston <toobaz a email.it> wrote:
>>>>         
>>  >>
>>  >>
>>  >>>  (O intendi qualcos'altro? Io per ora del tipo "set" sto usando update,
>>  >>>  remove, add, metodi che non vorrei dover ridefinire)
>>  >>>
>>  >>
>>  >> E non ridefinirli. Delegali.
>>
>>  Vabbé che "Google is my friend", ma certo sei un tantinello criptico
>>  (immagino si evinca dai miei messaggi precedenti quanto io sia poco
>>  esperto di Python)?
>>     
>
> Non è questione di esperienza di Python. E' una tecnica iper-standard
> di programmazione agli oggetti.
>   

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

> Tipicamente quando progetti una qualunque gerarchia di classi una
> delle prime domande che ti devi porre è se usare ereditarietà o
> composizione (tipicamente l'ereditarietà è spesso usata a sproposito).
> Quando usi composizione spesso fai anche delega (specie nei casi in
> cui eri in lizza con l'ereditarietà pubblica).
>
>   
>>  "delegare" significa in pratica "richiamare esplicitamente il metodo di
>>  libreria all'interno del metodo che si ridefinisce"? Tipo
>>
>>  class nonderivata():
>>     def __fai_questo__(self):
>>         set.__fai_questo__(self)
>>
>>  ?
>>
>>  Se sì, che ci guadagno?!
>>  Se no, che vuol dire?!
>>     
>
> Kind of. In effetti *non* è come dici, ma ci vai vicino. Il caso base sarebbe
>
> class my_obj(object):
>   def __init__(self):
>     self.contents = set()
>
>   def foo(self):
>     return self.contents.foo()
>
> Ovviamente visto che Python è un linguaggio dinamico non hai necessità
> di farlo veramente ma puoi semplicemente scrivere il codice per
> generare questo codice per i metodi di interesse.
>   

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à.

> Cosa ci guadagni? E' la solita banale fra "is a" e "has a". Quando usi
> ereditarietà per modellare una relazione di has-a, stai chiedendo
> guai. Comunque non credo sia il caso di fare qui un mini-corso di
> fondamenti di progettazione ad oggetti  e non conosco risorse
> direttamente in Python per farlo.
>   

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ì.

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...

Il problema è che non sapevo che l'hash deve rimanere immutato, e avrei
fatto lo stesso errore anche con il contenimento.

> Potrei indicarti alcuni articoli di Martins
>
> http://www.objectmentor.com/resources/articles/lsp.pdf
>   

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...

> http://www.objectmentor.com/resources/articles/ocp.pdf
>   

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?!

Pietro