[Python] Ma Go non ha le classi

[enrico franchi]

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-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150326/e8d322c1/attachment.html>