I linguaggi a oggetti possono essere Class Based (come Java) o Object Based (come JavaScript).
Il giorno 27 marzo 2015 00:49, enrico franchi <[email protected]> ha scritto: > > > 2015-03-26 22:17 GMT+00:00 Gian Mario Tagliaretti <[email protected] > >: > >> Il 26 marzo 2015 22:16, Carlos Catucci <[email protected]> ha >> scritto: >> >> ciao Carlos, >> >> > Scopro solo ora (ni ritagli di tempo mi sto guardando questo >> linguaggio) che >> > Go non ha le classi. Va considerao lo stesso un linguaggio OOP? >> >> La risposta ufficiale è "yes and no": >> > > 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. > > 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. > > Kay diceva: "OOP to me means only messaging, local retention and > protection and hiding of state-process, and extreme late-binding of all > things". > > 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. > > Incidentalmente l'ereditarieta' era proprio una cosa che Kay aveva > inizialmente lasciato fuori: > > """" > - I didn't like the way Simula I or Simula 67 did inheritance > (though I thought Nygaard and Dahl were just tremendous thinkers and > designers). So I decided to leave out inheritance as a built-in > feature until I understood it better. > """ > > 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. > > 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. > > 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". > > > >> http://golang.org/doc/faq#Is_Go_an_object-oriented_language >> >> Non sono tanto d'accordo sull'ultima frase, ma forse è solo una forma >> mentale dura da scrostare. >> > > 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. > > Pero' ancora una volta... il fatto che le interfacce sono sempre > post-facto, semplifica dannatamente un sacco di cose. > > 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. > > > -- > . > ..: -enrico- > > _______________________________________________ > Python mailing list > [email protected] > http://lists.python.it/mailman/listinfo/python > >
_______________________________________________ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
