<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-03-26 22:17 GMT+00:00 Gian Mario Tagliaretti <span dir="ltr"><<a href="mailto:g.tagliaretti@gmail.com" target="_blank">g.tagliaretti@gmail.com</a>></span>:<br><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">Il 26 marzo 2015 22:16, Carlos Catucci <<a href="mailto:carlos.catucci@gmail.com">carlos.catucci@gmail.com</a>> ha scritto:<br>
<br>
ciao Carlos,<br>
<span class=""><br>
> Scopro solo ora (ni ritagli di tempo mi sto guardando questo linguaggio) che<br>
> Go non ha le classi. Va considerao lo stesso un linguaggio OOP?<br>
<br>
</span>La risposta ufficiale è "yes and no":<br></blockquote><div><br></div><div>Che ovviamente e' l'unica possibile come "ufficiale". La risposta "vera" e' probabilmente "si", ma scrivere in una faq che chi pensa che un concetto chiave dell'OOP sia l'ereditarieta' ha torto completo, anche perche', a dirla tutta, chiedi a 10 persone cosa sia l'OOP e ti diranno 10 cose diverse. E nota, non parlo di 10 persone la cui somma delle conoscenze su OOP e' un sottoinsieme di quello che hanno letto sul deitel&deitel.</div><div><br></div><div>In pratica non c'e' una definizione su cui siamo tutti d'accordo, di conseguenza e' complicato dire cosa sia OOP e cosa non lo sia. Ci sono cose che si sono proclamate OOP con tale vigore che ora nessuno lo mette in discussione, ma la cosa finisce li.</div><div><br></div><div>Kay diceva: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things". </div><div><br></div><div>Ora... Go queste cose le ha. Ci sono i messaggi (ah, per Kay "messaggio" vuole dire "chiamata di metodo", in essenza), ci sono "(local retention, protection, and hiding) of state-process", c'e' il late binding.</div><div><br></div><div>Incidentalmente l'ereditarieta' era proprio una cosa che Kay aveva inizialmente lasciato fuori:</div><div><br></div><div>""""</div><div>  - I didn't like the way Simula I or Simula 67 did inheritance </div><div>(though I thought Nygaard and Dahl were just tremendous thinkers and </div><div>designers). So I decided to leave out inheritance as a built-in </div><div>feature until I understood it better. </div><div>"""</div><div><br></div><div>Ci sono persone che vedono la chiamata di metodo come "troppo poco", ovvero che nei sistemi "veramente OOP" il disaccoppiamento degli oggetti e' molto piu' alto che in affari tipo Java o Python, ed essenzialmente trovano Attori e Agenti come la "vera" incarnazione dell'OOP. Da cui si deriva che secondo questa interpretazione Erlang e' nonostante tutto un linguaggio ben piu' ad oggetti dei "classici". E anche qui Go non se la cava male. Certo, con il focus su CSP invece che Actor Model bisogna guardare bene per trovarlo, ma alla fine dei conti si fa. Sebbene sia potenzialmente piu' tirato. </div><div><br></div><div>Nota, io sono in sostanziale accordo con Kay, nel senso che anche per me quello e' quello che conta nell'OOP. Aggiungo che momenti l'ereditarieta' usata con la vanga in stile anni '90 ha quasi ammazzato il tutto; fortunatamente poi si e' rinsaviti. Ma non e' che veramente mi interessi un dibattito su cosa sia l'OOP. Diciamo che per varie definizioni di OOP, Go e' completamente OOP. </div><div><br></div><div>Se invece per dire intendiamo con OOP "Java" (ovvero, prendiamo le caratteristiche di un object model affine a quello di Java come definizione di OOP), allora Go non e' OOP. Da cui appunto capisco che l'unica possibile risposta ufficiale e' "si e no".</div><div><br></div><div> </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">
<a href="http://golang.org/doc/faq#Is_Go_an_object-oriented_language" target="_blank">http://golang.org/doc/faq#Is_Go_an_object-oriented_language</a><br>
<br>
Non sono tanto d'accordo sull'ultima frase, ma forse è solo una forma<br>
mentale dura da scrostare.<br></blockquote><div><br></div><div>Io invece in qualche modo la sento. Non riesco a motivare oggettivamente, ma ho l'impressione che in qualche modo gli oggetti in Go siano qualcosa di piu' leggero. Non necessariamente come runtime... come overhead cognitivo. Pero' sempre per lo stesso motivo, appena uno inizia a vedere le struct di Go come collezioni di dati (e vede prima le struct delle interfacce) ecco che effettivamente l'OOP se ne va a spasso.</div><div><br></div><div>Pero' ancora una volta... il fatto che le interfacce sono sempre post-facto, semplifica dannatamente un sacco di cose. </div><div><br></div><div>Poi mi aspetto che quando ci sara' una code base di Go comparabile a quella di Java, ci si trovera' a dovere introdurre le implementazioni di default dei metodi per potere toccare minimamente la libreria standard. A meno che i progettisti non si siano fatti pure loro un giro sulla macchina del tempo di Guido e non hanno cannato un tubo. Pero' effettivamente proprio perche' le interfacce sono postfacto, potrebbe non essere troppo dolorosa sta roba... devo meditare.</div><div><br></div><div> </div></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>