<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> Tipicamente le idee alla base della progettazione ad oggetti sono *talmente*<br>
> buone [si lo so, non ho definito quello che e', almeno per me] che e'<br>
> *difficile* sostenere che farne a meno sia una buona idea.<br>
<br>
</span>Tu quoque, Rik0, fili mi!<br></blockquote><div><br></div><div>;)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Non dovresti sostenere che l'OOP facccagare, e la Programmazione<br>
Funzionale e` l'Unica Vera Via™?</blockquote><div><br></div><div>Mah... verrebbe da liquidarsela con un "dipende".</div><div>Alla fine dei conti mi piace veramente tanto, ma anche li... la piu' grossa differenza concettuale che vedo e' che in uno stile funzionale si rifiuta la modifica di stato, viceversa nell'OOP e' abbastanza centrale (sebbene si possa certamente lavorare senza modificare lo stato).</div><div><br></div><div>Per il resto, LOL e compagnia non sono strettamente incompatibili con la programmazione ad oggetti (lasciando anche stare il solito discorso che un oggetto e' proprio una chiusura lessicale). </div><div><br></div><div>Alla fine dei conti anche molto codice "apparentemente" funzionale finisce per non essere funzionale come dovrebbe. Nei linguaggi ibridi almeno e' comune. Esattamente come e' comune in Python tirare dentro altri stili. Quindi temo che non sara' facile farsi un'esperienza tale in linguaggi puri per capire quanto mi piace davvero... l'idea e' eccellente. Ci sono cose per cui vedo che funziona davvero bene. Ci sono altre cose che ho gia' incontrato dove non mi sono trovato troppo a mio agio (senza poter "rompere il modello").</div><div><br></div><div>Viceversa, con la programmazione ad oggetti non mi sono mai trovato nel caso di voler "rompere il modello". Mi sono trovato a volere che le API di qualcosa fossero diverse, certo. Mi sono trovato a volere che una certa cosa avesse meno stato implicito (e questa sebbene non esca dal modello OOP e' forse l'unica cosa relativa al "modello"). Mi sono trovato spesso a volere determinate funzionalita' di altri linguaggi... ma non necessariamente fuori dal modello. Per dire, ultimamente mi piace molto l'idea di un type-system forte come quello di Haskell. E in particolare la cosa che mi manca di piu' e' newtype...</div><div><br></div><div>Oh, che voglio dire HM e' ben diverso dal classico modello ad oggetti. Ma non mi verrebbe dire che quando uno progetta una struttura del gente alla fine dei conti non stia comunque facendo OOP. Alla fine dei conti quello che cambia davvero e' la relazione fra dati e funzioni, ma non e' che non si possa intendere quello che si fa in senso OOP. E sempre alla fine dei conti SOLID rimarrebbe piu' o meno sempre valido. E quindi...</div><div><br></div><div><br></div></div><div><br></div>-- <br> .<br>..: -enrico-
</div></div>