<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2014-12-09 16:46 GMT+00:00 Marco Ippolito <span dir="ltr"><<a href="mailto:ippolito.marco@gmail.com" target="_blank">ippolito.marco@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ciao Enrico,<br>
ammetto la mia ignoranza.<br>
non capisco perchè in python dovrebbe essere un controsenso.<br>
<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Se ho capito bene il senso (scusate il gioco di parole) del design by<br>
contract, l'obiettivo è quello di "dichiarare" in qualche modo<br>
all'inizio cosa deve produrre un certo pezzo di codice, quali input<br>
sono accettabili per esso, e le condizioni che devono rimanere vere<br>
per il chiamante.<br></blockquote><div><br></div><div>Non e' solo *dichiararlo*. E' *definirlo*, ma soprattutto *verificarlo*.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Come dici tu queste idee di fondo mi sembrano essere buone, nel senso<br>
che aiutano a pensare il codice in termini di "service" fornito<br>
reciprocamente dai vari componenti, e questo rende il tutto più<br>
facilmente testabile.<br></blockquote><div><br></div><div>Non e' solo questione di essere *testabile*. Essenzialmente si tratta di roba che e' formalmente dimostrabilmente corretta e che, di conseguenza, non necessariamente dovrebbe avere bisogno di "test" in senso stretto, perche' l'ambiente dovrebbe fare i test in modo automatico. Di fatto, un buon numero di test dovrebbero diventare ridondanti. E tipicamente vuoi che sia fatto *staticamente*. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Perchè in python dovrebbe essere un controsenso?<br></blockquote><div><br></div><div>Perche' e' un linguaggio completamente dinamico che vive praticamente interamente a runtime.</div><div>L'unico punto in cui e' veramente possibile fare le verifiche e' a runtime. E in generale si tratta di roba relativamente costosa da verificare (perche' vuoi che i contratti siano sensati, non limitarti a quelli facili da testare). </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Quello che alla fine vorrei utilizzare in modo pratico e concreto è<br>
delle modalità meglio se codificate e già in uso, che mi aiutino a<br>
pensare in anticipo a modi "intelligenti" di scrivere il codice.  Non<br>
potrebbe servire l'approccio Design by Contract?<br></blockquote><div><br></div><div>Boh. "Potrebbe" servire, certo. Metti conto che la metodologia come definita da manuale non mi risulta usata praticamente da nessuno. Per me e' una di quelle cose che a volte torna comoda come strumento concettuale, ma poi la cosa finisce li. </div><div><br></div><div>In generale fa bene sapere che c'e', fa bene sapere come funziona. Fa anche bene saperci ragionare. Ma poi, per me, finisce li. YMMV.</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>