enrico franchi ha scritto: > 2008/5/5 Pietro Battiston <[EMAIL PROTECTED]>: > >> 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. >
Perché un vertice - nella mia applicazione - è prima di tutto la giunzione di diversi lati. Voglio potere ad esempio congiungere (union, o update) due vertici, ovviamente non voglio lati doppioni in uno stesso vertice. Poi ha il campo ID che serve sostanzialmente a distinguere i vertici e togliere di mezzo quelli ormai inutili. Peraltro l'assunzione "due vertici sono uguali solo se //contengono le stesse cose//" rimane vera (tranne che per i vertici ormai vuoti). > 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. > Maneggio dei particolari grafi (sviluppi piani di poliedri e cose simili). So che ci sono librerie fantasmagoriche per i grafi, ma avrei comunque dovuto aggiungere un sacco di caratteristiche (ad esempio, le facce e la loro orientazione), per cui ho preferito partire da zero. Ovviamente di un vertice mi interessano i lati che ci arrivano, mentre dell'ordine me ne frego abbastanza (in realtà questa è più che altro una scelta, perché semplicemente l'ordine non mi interessa per quel che dovrò poi farci). >> 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. > Sì, sul principio generale hai perfettamente ragione. La verità è che se mai deciderò che val la pena pubblicare quel che sto facendo, dovrò ovviamente essere certo che ogni metodo che la mia classe ha (o eredita) sia consistente, e in quel caso viva il duck typing, ma finché è una roba mia mi fa estremamente comodo, spippolando con ipython, avere a portata di mano tutto e subito per sperimentare, e magari fare anche cose non consistenti (per debug, mi sono addirittura //scritto// metodi che rendono il tutto non consistente). E che comunque lavorare in modo "pulito" non avrebbe risolto il problema per cui avevo scritto in lista. >> 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. > Certo, per qualcosa che dovessi rilasciare al pubblico non avrei dubbi. Per quel che riguarda me, preferisco che le funzioni "dalla coerenza incerta" ci siano piuttosto che siano nascoste. >> 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. > Sì, abbastanza. Forse la cosa non mi tange troppo solo perché non ho mai partecipato all'"evoluzione" di niente in Python, finora quello che ho scritto l'ho scritto sempre da solo, e tutti i miei moduli erano di "alto livello" (non nel senso di qualità ma di specializzazione). Pietro _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
