Newsgroup: it.comp.programmare
Titolo: Che mi dite sull ' O O ??

Ciao a tutti, mi rivolgo ai più esperti e a quelli con maggiore esperienza:
volevo un parere personale su Java come linguaggio O O , volevo sapere quali
sono in fin dei conti i vantaggi e quali i difetti, volevo rendermi conto a
cosa vado incontro se scelgo il C invece del Java ecc ecc.
Che mi dite?
RISPONDETE IN NUMEROSI MI RACCOMANDO!  :-)
Ciao e thanks!

 RISPONDETE IN NUMEROSI MI RACCOMANDO!  :-)
1
ciao
-- 
We are just like a sandglass, 
a life inserted by someone else into a glass, 
the time that has been given us it's brief, we can't stay shut in here, 
even at the cost of breaking the glass, we must go out.


Non vorrei sbagliarmi, ma il java mi pare non supporti l'ereditarieta'
multipla. Se qualcuno puo' confermare... io il java l'avevo usato solo per
un progettino all'universita'.
Luca

multipla.
Vero, anche se questo non inficia la sua natura object-oriented.
-- 
Andrea Laforgia
#exclude <windows.h>

 un progettino all'universita'.
...Non proprio.
In effetti una sottoclasse può avere una sola superclase, ma esistono
delle scappatoie, tipo ereditare da un package.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 scelta intelligente in alcune occasioni
inizio a pensare che quelle occasioni siano solo
i sistemi real-time, i driver e cose affini :)
-- 
Rhymes
rhy...@NOSPAMmyself.com

 Vero, anche se questo non inficia la sua natura object-oriented.
gia`, la sua natura object oriented e` inficiata da ben altre cose :-))
ciao Anto
PS: questo e` un post semiserio... lo sapete che java non lo digerisco 
per nulla!
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

gia`, la sua natura object oriented e` inficiata da ben altre cose :-))
Cioč ?


 
Ereditare da un package???cosa intendi? Mi dai l'indirizzo del tuo 
spacciatore ? Usi il Jdk della microsoft :-))) 
Apparte gli scherzi...
L'unica scappatoia è utilizzare le interfacce...
Ciao
Dany
-- 
Daniele Piras
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If at first the idea is not absurd then there is no hope for it. - Albert
Einstein
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 L'unica scappatoia è utilizzare le interfacce...
http://www.dimi.uniud.it/~mizzaro/LibroJava/lucidi/cap10.pdf
Leggilo.


 Leggilo.
Bello letto .. e quindi???? Forse hai sbagliato a chi rispondere :P


> Bello letto .. e quindi???? Forse hai sbagliato a chi rispondere :P
Scusa.


 Cioč ?
ad esempio il fatto che un mucchio di cose in java non sono oggetti: un 
tipo non e` un oggetto, una classe non e` un oggetto, una variabile di 
tipo built-in non e` un oggetto, un metodo non e` un oggetto, ecc.
Anche il C++ ha le stesse limitazioni, ma almeno in quel caso hanno uno 
scopo: l'efficienza.
Ovviamente l'efficienza non e` lo scopo di java, ma allora i conti non 
tornano: IMHO ci sono alcune caratteristiche che non hanno senso nel 
contesto di java: una e` quella che ho citato, un'altra e` ad esempio la 
tipizzazione statica: quest'ultima offre due vantaggi considerevoli 
rispetto alla tipizzazione dinamica:
1) permette al compilatore di ottimizzare in modo piu` aggressivo
2) permette di avere un miglior controllo statico sulla correttezza di un 
programma.
Ora, nel contesto di java, entrambi questi vantaggi sono annullati o 
quantomeno "mutilati": il punto (1) non ha neppure senso di esistere, in 
quanto java non e` certo progettato per essere efficiente e ci sono 
altre features (ad esempio il garbage collector) che incidono di piu` 
che non un eventuale tipizzazione dinamica.
Il vantaggio numero (2) e` decisamente inficiato dalla libreria standard 
del linguaggio: la mancanza di "generics" ha inevitabilmente portato la 
libreria ad abusare dell'ereditarieta` da Object, costringendo il 
programmatore ad innumerevoli cast: ogni volta che c'e` un cast il 
controllo statico sparisce e diventa dinamico.
Nella mia (fin'ora fortunatamente breve) esperienza di java ho notato che 
molto spesso il controllo statico era *decisamente* inferiore a quello 
che sarebbe stato in, ad esempio, C++.
Un'altra caratteristica che contribuisce a "smantellare" il punto (2) e` 
la mancanza di (soprattutto) covarianza e controvarianza: anche in 
questo caso non riesco a trovare un buon motivo per giustificarne la 
mancanza.
In definitiva direi che java e` OO tanto quanto lo e` il C++ (eccezion 
fatta per l'ereditarieta` multipla), pero` almeno il C++ ha dei buoni 
motivi per fare quel che fa :-))
ciao Anto


 multipla
solo tramite interfaccia
-- 
Rhymes
rhy...@NOSPAMmyself.com

 per nulla!
idem ma digerisco ancor di meno c++ ;-)
come mai non ti piace?
-- 
Rhymes
rhy...@NOSPAMmyself.com

In definitiva direi che java e` OO tanto quanto lo e` il C++ 
I tuoi motivi, che per certi versi si possono condividere, dimostrano
che Java ha delle differenze con il C++ e questo può bastare all'OP.  
Non detraggono nulla, però, alla sua natura OO.  Perché un linguaggio
si possa definire object-oriented, i requisiti da rispettare sono
veramente pochi.


 efficiente; l'efficienza riguarda l'_implementazione_ di un
Le possibili (e agevoli) implementazioni sono vincolate dai
parametri di progetto.  Suggerisco la lettura di "Design and
Evolution of the C++ Programming Language" di Stroustrup per
un eccellente "case study".  Il progetto del linguaggio C++
e` stato MOLTO vincolato da esigenze di pratica efficienza
delle implementazioni (sia di quelle effettivamente esistenti
sia di quelle realizzabili in modo ragionevolmente agevole,
cioe` senza dovere inventare meccanismi totalmente nuovi). 
Alex

 veramente pochi.
condivido. Come ho gia` detto, il mio post era piu` che altro 
provocatorio :-)


 come mai non ti piace?
nella risposta ad Andrea ho elencato alcune caratteristiche di java che 
proprio non digerisco: ce ne sono anche altre, ma elencarle tutte 
sarebbe troppo lungo... penso che un giorno scrivero` qualcosa del tipo 
"Java language considered harmful" ;-)
Ad esempio, mi piacerebbe che ci fosse la possibilita` di usare l'idioma 
RAII (resource acquisition is initialization) come si fa in C++, ma java 
(come del resto python :-( ) non offre alcuna garanzia sul tempo di 
chiamata dei distruttori, quindi non e` applicabile.
ciao Anto


un oggetto.  
Era appunto questo il nocciolo della questione.
Tutto è sapere se per object-oriented _puro_ si intende che *tutto*
debba essere oggetto o perlomeno rispettare i canoni di Python, ad
esempio.  Io credo che la natura _pura_ di un linguaggio OO sia quella
che si limiti a incarnare tutti e tre i cardini dell'OOP [1].
Tutto ciò che contorna[2] l'implementazione di questi "concetti" non
incide (in positivo o in negativo) sulla natura "object-oriented".
O mi sbaglio ?
-----
[1] incapsulazione/ereditarietà/polimorfismo.
[2] ereditarietà forzatamente singola o ereditarietà singola e
multipla, programmazione generica, allocazione statica/dinamica delle
istanze delle classi ecc....


cast!
Sì, lo fa e questo, possiamo essere d'accordo, costituisce una fonte
di inefficienza.


 di inefficienza.
Buon esempio (in C++, che E` progettato per l'efficienza massima
anche a scapito di rischiare gravi errori del programmatore, un
dynamic_cast<> in situazioni analoghe e` FACOLTATIVO -- inoltre
naturalmente l'uso dei template permette spesso l'efficienza
piu` spinta ed assoluta, in questo caso a scapito della complessita`
del linguaggio stesso).
Alex

implementazione del C++ che ne rispetti gli standard.
E` vero, hai ragione.


 motivi per fare quel che fa :-))
Sul C++ non si discute...l'unico neo (e forse non l'unico) è la
complessità ma credo derivi dal fatto che C++ è stato progettato per fare
praticamente tutto (anche se, visto che ti piace Python, puoi usarlo
sempre meno :)
-- 
Rhymes
rhy...@NOSPAMmyself.com

[...]C++ è stato progettato per fare praticamente tutto
Se solo tutti coloro che lo usano lo sapessero fare ;-)


 Se solo tutti coloro che lo usano lo sapessero fare ;-)
...non basterebbe ancora per giustificarne l'uso nella maggior
parte dei casi.  Io so (ancora) usare C++ abbastanza bene, ma
perche` dovrei se posso fare la stessa cosa in Python in, che
so, un quarto del tempo?
Alex

 _costringe_ ad avere un garbage collector.
Giusto -- ma la stessa costrizione si avrebbe anche se fosse
introdotto un deallocatore esplicito, se restasse il fatto di
non essere OBBLIGATI ad usarlo, cioe` di potere contare sul
fatto che un ciclo che esegue QUALSIASI numero di allocazioni
di (ad esempio) istanze di Integer, assegnandole tutte alla
stessa variabile, NON PUO`, MAI terminare per "fine memoria"
(a norma degli standard del linguaggio).
Insomma, la semantica di Java, Eiffel, Python, Common Lisp,
un po' tutti i buoni linguaggi moderni alla fin fine, e`
progettata per garantire contro i rischi di memory leak e
dangling references.  Se questo comporta NECESSARIAMENTE un
certo overhead (che Meyer stimava ad almeno il 30% nel caso
tipico) rispetto a linguaggi che sono invece progettati con
lo specifico obbiettivo di consentire "il 100% dell'efficienza",
come il C++, si tratta di una scelta deliberata e difendibile
da parte di tutti i progettisti dei tanti linguaggi suddetti.
I programmi dove un 30% di efficienza fa la differenza sono
una frazione modestissima; i bug legati alla gestione manuale
della memoria sono una iattura infinita.
Ma e` appunto importante rendersi conto che _C'E`_ un tradeoff:
il progetto del linguaggio, in una certa misura e in condizioni
(realistiche!) di risorse finite disponibili per ottimizzare
le implementazioni (e in certi casi anche incondizionatamente)
HA influenza sull'efficienza possibile nelle implementazioni.
Alex

assai piu` simile a Java che non a Delphi.
Non conosco benissimo C#, non conosco benissimo Java, ma da quel che
mi viene detto, Delphi e Java si somigliano moltissimo.


(a norma degli standard del linguaggio).
Sì, è vero; se ci sono questi vincoli, a livello di progettazione del
linguaggio, ovvero se è escluso che nei programmi vi possano essere
dei "memory leaks", è chiaro che si sta rimandando la "pulitura" della
memoria all'implementazione.   


 un progettino all'universita'.
non la supporta, se non usando delle interfacce, si nota subito visto
che l'utilizzo di una keyword come "super" preclude la possibilità di
poter scegliere il costruttore voluto durante l'overridding, infatti è
implicito che tu ne possa usare uno solo :)
ciao
-- 
We are just like a sandglass, 
a life inserted by someone else into a glass, 
the time that has been given us it's brief, we can't stay shut in here, 
even at the cost of breaking the glass, we must go out.

 esplicito le istanze ?
non mi pare che esista un "delete" o compagnia bella nel Java, è
sufficiente che cadano tutti i riferimenti ad un oggetto perchè questo
venga raccolto da gc


 mi viene detto, Delphi e Java si somigliano moltissimo.
Dissento, Il modello OO e' simile, infatti entrambi hanno una classe
base (Nel caso di Delphi TObject) e la RTTI, ma Java ha il garbage
collector e la Virtual Machine, Delphi no ed e' molto piu' efficente.
Secondo me Delphi e' un C++ con RTTI e senza ereditarieta' multipla.
Ciao...
Claudio Driussi

 veramente pochi.
Credo che Antonio non stesse obiettando sul fatto che Java sia OO ma sul
_come_ lo č
-- 
Rhymes
rhy...@NOSPAMmyself.com

 esplicito le istanze ?
puoi solo forzare la cosa
gc
public static void gc()
    Runs the garbage collector.
    Calling the gc method suggests that the Java Virtual Machine expend
    effort toward recycling unused objects in order to make the memory
    they currently occupy available for quick reuse. When control returns
    from the method call, the Java Virtual Machine has made a best effort
    to reclaim space from all discarded objects.
    The call System.gc() is effectively equivalent to the call:
 	Runtime.getRuntime().gc()
Trovi tutto qui
http://java.sun.com/j2se/1.4.1/docs/api/java/lang/System.html
-- 
Rhymes
rhy...@NOSPAMmyself.com

 dimenticatelo ;-)
Lo so ma bisogna riconoscere che Anders Helsjberg e il team di C# ha fatto
un buon lavoro. Idem per .NET in generale
ps. sto per provare Py4Delphi su Kylix3 OE per vedere che riesco a
combinare ;)
-- 
Rhymes
rhy...@NOSPAMmyself.com

 mi viene detto, Delphi e Java si somigliano moltissimo.
Mmm a me non sembra ma non essendo un esperto non posso confermare e
nemmeno smentire...io trovo molte più somiglianze tra C# e Java
-- 
Rhymes
rhy...@NOSPAMmyself.com

 chiamata dei distruttori, quindi non e` applicabile.
ignoro la cosa :)
-- 
Rhymes
rhy...@NOSPAMmyself.com

_come_ lo è
Non ci siamo.  Antonio stava volontariamente provocando e, visto in
questo senso, quanto ha affermato si può accogliere con un sorriso, ma
le motivazioni che ha addotto, come ho già detto (condivisibili in
molti punti) non aggiungono/tolgono nulla alla questione
"object-oriented".  Cioé, Java è OO esattamente come qualsiasi altro
linguaggio che si limiti a implementare i cardini del paradigma OO.


Secondo me Delphi e' un C++ con RTTI e senza ereditarieta' multipla.
Opinabile.  Senza aprire un dibattito sulla questione, Delphi non ha
_molte_ cose che, invece, il C++ ha.


Mmm a me non sembra 
E` cosě, fidati.


un buon lavoro.
Mai detto il contrario ;-)


 run-time sulla consistenza di tale cast!
Delphi, da bravo linguaggio compilato, non fa questo controllo. Se vuoi 
controllare che il tipo sia giusto, non usi un cast ma l'operatore as o  
il suo cugino is, che credo usino RTTI
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.0.21. C/C++ and ASM developers
                               and beta testers are welcome!

 scritti con esso,
Java č tutto indirezioni doppie/triple/n-ule, et gai saltelli di vtable 
in vtable. C++ sacrifica un po' del proprio orientamento ad oggetti con 
i template, dove il Java pretenderebbe di scoprire a runtime il tipo di 
ogni variabile, o fare liberamente uso di type inferencing, manco fosse 
un linguaggio interpretato. Mi spiegava un Javista invasato che in Java 
i template non dovrebbero mai essere introdotti, perchč dovrebbe essere 
il compilatore a predisporre l'output intermedio in tal guisa


 _molte_ cose che, invece, il C++ ha.
E' una questione di opinioni, il compilantore Java produce una spece
di pcode che necessita di una virtual machine per funzionare, Delphi
produce codice macchina, Java di porta dietro una enorme libreria che
viene linkata a runtime, Delphi invece produce eseguibili indipendenti
queste a me sembrano differenze inportanti.
Ciao...
Claudio Driussi

queste a me sembrano differenze inportanti.
Quando parlo di _somiglianze_ tra Java e Delphi sto _sottointendendo_
queste differenze; io mi sto riferendo al linguaggio in sé.  Delphi è
Java, a livello di linguaggio, hanno _molte_ somiglianze, anche se vi
sono queste differenze nella produzione del codice.


 i miei dubbi.  
[mega-cut]
visto che Alex mi ha preceduto e ha spiegato quel che volevo dire in modo 
molto piu` chiaro di quanto non avrei fatto io, evito di rispondere... 
;-)
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 ignoro la cosa :)
 
l'idioma RAII e` molto diffuso in C++ ed in sintesi funziona cosi`: ogni 
volta che devi gestire una risorsa la deleghi ad una classe, che si 
occupera` di allocarla (nel costruttore) e di deallocarla (nel 
distruttuore).
Alcuni esempi di classi RAII sono gli stream su file e auto_ptr:
void foo()
{
    std::ofstream output("nomefile");
    std::auto_ptr<int> p(new int);
    output << "ciao ciao";
    // altre operazioni
}
Come vedi non mi sono preoccupato ne` di chiudere il file ne` di 
distruggere il puntatore: ci pensano i distruttori di ofstream e 
auto_ptr a farlo al posto mio.
Come gia` accennavo prima in (ad esempio) java e python questo non e` 
possibile perche` non offrono alcuna garanzia sulla chiamata dei 
distruttori: potrebbero essere chiamati subito, dopo qualche minuto, 
dopo qualche ora o addirittura mai: ovviamente il programmatore si trova 
obbligato a chiudere manualmente la risorsa, dato che deve essere sicuro 
che, ad esempio, il file venga scritto su disco (tralascio complicazioni 
dovute alla cache gestita dal sistema operativo); un altro esempio di 
risorsa potrebbe essere un mutex: anche in questo caso il mancato 
rilascio del mutex puo` avere conseguenza catastrofiche sul programma, 
quindi e` bene deallocarlo a mano.
Ecco un esempio in python:
def foo():
    output = open('nomefile', 'w')
    output.write('ciao ciao')
    # altre operazioni
    output.close()
Purtroppo questo codice e` parzialmente insicuro: se le "altre 
operazioni" sollevano una eccezione la funzione uscira` senza chiamare 
la close() e il file potrebbe non essere chiuso.
Il modo corretto di operare e` usare try...finally:
def foo():
    output = open('nomefile', 'w')
    try:
        output.write('ciao ciao')
        # altre operazioni
    finally:
        output.close()
In questo modo ci cauteliamo e siamo sicuri che la close() sara` sempre 
chiamata; le cose si complicano quando dobbiamo allocare piu` di una 
risorsa nella stessa funzione (ad esempio un mutex e un file): in questo 
caso dobbiamo essere piu` cauti:
def foo():
    mutex = acquire_mutex()
    try:
        output = open('nomefile', 'w')
        try:
            # operazioni varie
        finally:
            output.close()
    finally:
        mutex.release()
dal codice sopra si puo` facilmente capire perche` rimpiango questa 
caratteristica del C++.
Da notare che in CPython (ovvero il python "normale") siamo 
ragionevolmente sicuri che tutto vada per il meglio: una parte del 
garbage collector e` implementata mediante reference counting, per cui 
all'uscita della funzione gli oggetti riferiti da 'output' e 'mutex' 
saranno distrutti in quanto non piu` referenziati.
Ma il manuale di riferimento del linguaggio (lo "standard") non 
garantisce questo comportamento, ed in effetti esiste un'altra 
implementazione, Jython, per cui questa assunzione non vale: per cui se 
uno vuole scrivere codice python realmente portabile deve usare 
try...finally :-(


 implicito che tu ne possa usare uno solo :)
non e` del tutto vero: le ultime versioni di python (si, ancora lui! ;-) 
hanno il comando (in realta` e` un oggetto) super che funziona bene 
anche con l'ereditarieta` multipla. Se Alex e` ancora ne paraggi sapra` 
spiegare meglio di me come funziona, altrimenti se ti interessa dovrai 
accontentari di una mia orribile spiegazione :-)


[...]evito di rispondere... 
Però gradirei ancora avere quegli esempi...


 accontentari di una mia orribile spiegazione :-)
Riassumendo: in Python (2.2 e successivi), super prende come
argomento ANCHE la classe lungo la quale si cerca la superclasse.
Ad es:
class Y(object):
    def xxx(self):
        print "Y.xxx"
        try: super(Y, self).xxx()
        except AttributeError: pass
class Z(object):
    def xxx(self):
        print "Z.xxx"
        try: super(Z, self).xxx()
        except AttributeError: pass
class X(Y, Z):
    def xxx(self):
        print "X.xxx"
        super(X, self).xxx()
x=X()
x.xxx()
emette:
[alex@lancelot probnut]$ python a.py
X.xxx
Y.xxx
Z.xxx
perche` la superclass di x "lungo X" risulta Y, ma "lungo Y"
risulta Z (e "lungo Z" risulta object, che non ha un metodo
chiamato 'xxx', il che spiega i try/except in Y e Z...).
In altri termini la struttura di eredita` multipla viene
"dipanata" nel method-resolution-order (MRO), l'ordine in
cui Python "cerca" metodi e altri attributi fra le varie
classi e superclassi, in questo caso X Y Z object; e la
built-in super di Python "cammina" su questo MRO senza
nessuna implicita "magia nera" (infatti devi passare sia
il tipo da cui partire per il passo successivo, sia lo
specifico oggetto self su cui lavorare).
La stessa soluzione si potrebbe ottenere anche preferendo
la magia nera (super senza espliciti argomenti) visto che,
volendo, il compilatore potrebbe applicarla.
Alex

 il compilatore a predisporre l'output intermedio in tal guisa
Credo che saranno introdotti i generics dalla prossima versione...
-- 
Rhymes
rhy...@NOSPAMmyself.com

 caratteristica del C++.
grazie.
-- 
Rhymes
rhy...@NOSPAMmyself.com

Java č tutto <...>
Parli come se ci capissi qualcosa ;-)


 un linguaggio interpretato.
ancora una volta, cosa c'entra il type inferring (inferencing?) 
(caratteristica del linguaggio) con il fatto che sia compilato o 
interpretato (caratteristica dell'implementazione)?
Ad esempio, OCaml e` notoriamente dotato di un ottimo sistema di type 
inferring, ma oltre all'interprete esiste anche un compilatore.


 interpretato (caratteristica dell'implementazione)?
"caratteristica dell'implementazione" fino ad un certo punto. Sarà pure 
un caso limite, ma mi dici come si fa a compilare Javascript? So che fa 
sempre comodo sognare di vivere in un mondo di purezza ingegneristica - 
però ci sono certe possibili caratteristiche dei linguaggi che forzano, 
o comunque limitano le scelte implementative
Comunque. Non è mia intenzione (mai stata) di parlare di questo


 Perň gradirei ancora avere quegli esempi...
scusa, mi devo essere perso qualcosa: quali esempi?


 wrote:
[CUT]
Sbaglio o da qualche tempo a questa parte ti piace sernificare i testi
che scrivi?
Riccardo
--
La felicita' di un uomo dipende dalle donne che non ha sposato
<O.Wilde>

scusa, mi devo essere perso qualcosa: quali esempi?
Leggi il mio messaggio.


un caso limite, ma mi dici come si fa a compilare Javascript? 
Ci spieghi a che servirebbe compilare un codice Javascript ?
Javascript è un linguaggio di script, un linguaggio masticato dai
browser per svolgere determinate funzioni, a cosa giova compilarlo ?


 testi che scrivi?
yay. Che io sappia, sono anche l'unica a sernificare anche la signature 
e l'intestazione dei reply - nonchè l'unica ad allineare tutto, sempre, 
alla colonna 72



   Il web server della Netscape, ovviamente, ha un rapporto privilegiato 
con Javascript, ed i "servlet" in questo linguaggio sono precompilati 
(non ho idea in quale formato, presumo non eseguibile) per incrementare 
le prestazioni. Anche gli script JScript di 
ASP.NET
, in fondo, subiscono 
una sorta di compilazione. A nessuno, comunque, verrebbe in mente di 
compilare gli script client-side da scarivare con il browser.
-- 
Alla prossima,
Marco

alla colonna 72
Complimenti, non ci ho mai provato ma non credo sia semplicissimo.
Permettimi di dire pero' che a volte il risultato lo ottieni con
l'escamotage del trattino ' - ' che non sempre ci sta a pennello. Cio'
non toglie comunque che il risultato ottenuto e' notevole.
Ma dimmi la verita', quanto ci impiegheresti a scrivere qualcosa
simile a questo:
http://snurl.com/p42
sinceramente eh? :-)


 
http://snurl.com/p42
carino :-) probabilmente tre o quattro reincarnazioni. Ma quello che si 
riscrisse la Divina Commedia (rispettando la metrica, per di piů) senza 
usare la lettera O (in enigmistica si chiama "lipogramma", perchč frasi 
riscritte in questo modo tendono ad "ingrassare" parecchio) sicuramente 
ci mise di piů :-)


le prestazioni.
Non č propriamente ciň che si intende per "compilazione", almeno ciň
che intendevo io, quando ho posto la domanda.  Anche il codice Java č
precompilato, prima di essere eseguito dall VM, ma rimane pur sempre
interpretato.


 alla tipizzazione statica/dinamica.  Mi fai un esempio ?
pero` non capisco che esempio ti dovrei fare: ho inserito quella frase 
nell' "elenco di features che pregiudicano la massima efficienza": la 
tipizzazione dinamica introduce un certo overhead dato che ogni istanza 
si deve "portare dietro" le informazioni sul proprio tipo e il 
compilatore deve sempre inserire dei controlli a run-time per verificare 
che tutto vada per il meglio.
E` piu` chiaro ora? Oppure non ho capito la tua domanda?


 distruttori:
In Python *nell'attuale versione* funziona (se non ci sono riferimenti 
ciclici).
Molti dicono che il garbage collector di Python cambierà nelle prossime 
versione ma onestamente non so come senza "rompere" il codice C esistente 
che usa il reference count.
-- 
Marco Barisione

 try...finally :-(
Comodo, sicuro, portabile... 
eh, sě...
il Python č proprio meglio del C++...
ti fa risparmiare tempo...
:-D :-D :-D
Azathoth ... *no*comment* ...

 ciclici).
si lo so. Pero` non funziona, ad esempio, con Jython, quindi preferisco 
scrivere codice portabile tra CPython e Jython.
