[Python] Ma Go non ha le classi

[Luca Bacchi]

I linguaggi a oggetti possono essere Class Based (come Java) o Object Based
(come JavaScript).

Il giorno 27 marzo 2015 00:49, enrico franchi <enrico.franchi a gmail.com> ha
scritto:

>
>
> 2015-03-26 22:17 GMT+00:00 Gian Mario Tagliaretti <g.tagliaretti a gmail.com
> >:
>
>> Il 26 marzo 2015 22:16, Carlos Catucci <carlos.catucci a gmail.com> 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
> Python a lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150327/09fda76d/attachment.html>