Newsgroup: it.comp.programmare
Titolo: Quale linguaggio? x programmare?

Vorrei riprendere a programmare, in passato (10 anni fa)ho fatto programmini
in BASIC e ASSEMBLER x Commodore 64.
Quale linguaggio mi consigliate?
Java, Visual Basic, c, c++ o altro.
Premetto che non voglio fare programmi eccessivamente complicati xche non ho
molto tempo, ma voglio dilettarmi e cercare di capire la programmazione
moderna.
Ciao
Grazie
--
Bax

Java, Visual Basic, c, c++ o altro.
Python
se nn hai tempo da perdere nella sintassi e beghe varie...ti
consiglio questo
www.python.org
www.python.it
e se vuoi una guida per iniziare
http://www.aleax.it/Python/index.htm
--
Lawrence "Rhymes" Oluyede
rhy...@myself.com
Redattore di HiT
http://hit.edengames.net

 ha scritto nel messaggio
news:Vu0n8.60910$%g7.19...@twister2.libero.it...

Se il tuo obiettivo e' quello di riuscire rapidamente a sviluppare piccole
applicazioni personali in ambiente windows allora ti consiglio Visual Basic
se non altro perche', in tale modo, puoi riutilizzare alcune delle
conoscenze di Basic che già possiedi.
Se invece vuoi comprendere le tecniche di programmazione piu' utilizzate
allora ti consiglio di leggere qualche libro teorico di programmazione
orientata agli oggetti ed orientata ai componenti; fatto ciò avrai le
conoscenze necessarie per capire appieno i vari linguaggi di programmazione
e per scegliere quello che piu' risponde alle tue esigenze. Ti dico questo
in quanto, IMHO, un linguaggio e' migliore degli altri solo se rapportato al
tipo di applicazione da sviluppare; non esiste un linguaggio che e' in
assoluto migliore degli altri.

moderna.
Delphi e' la scelta migliore.
Ti sconsiglio vivamente il Visual Basic.
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]


Certo mi ero dimenticato di Delphi che e' un ottimo ambiente RAD basato su
un buon linguaggio quale Object Pascal.
Anche in questo caso torno a ribadire la mia personale idea: penso che a
priori non si possa sconsigliare vivamente un linguaggio/ambiente di
programmazione senza tenere conto delle situazioni nelle quali deve essere
utilizzato.
Ciao, Davide ;)

utilizzato.
Delphi č utilizzabile per quasi tutto
Python per tutto :)


utilizzato.
Senza voler scatenare l'ennesima guerra di religione, non
riesco proprio ad immaginare un ambito in cui si debba
preferire il Visual Basic a Delphi.  Visto che quest'ultimo,
a mio parere, prende il primo e se lo infila nel taschino ;)
e che puo' essere usato in *qualsiasi* ambito si usi il
primo, lo consiglio vivamente.  Ci sono tantissimi argomenti
tecnici e concreti che si potrebbero tirare in ballo per
trasformare quello che puo' apparire come un semplice punto
di vista in un dato di fatto.  Considera solo una cosa: e'
molto facile che un programmatore passi da VB a Delphi
(accade ogni giorno), e' praticamente impossibile il
contrario (se non per mere esigenze di lavoro).  Una volta
apprezzati i benefici di una programmazione object-based,
object-oriented (il parco di componenti (non scomodissimi
OCX) disponibili e' vastissimo), nonche' cross-platform, e'
difficilissimo tornare indietro.  Personalmente ho
programmato saltuariamente in Visual Basic (quindi non parlo
per sentito dire), l'ho fatto a malincuore, perche'
costretto ad integrarmi ad altri programmatori ed
essenzialmente per risolvere i problemi del *loro* software
scritto in VB in relazione al mio, scritto in Delphi.  
Goffo e ridicolo, senza alcuna forma di protezione per il
programmatore (ti fa perdere ore nella ricerca di bug
subdoli) con delle procedure di installazione del software
macchinose e scomodissime.
Non c'e' niente da fare: e' un BASIC, un software di base.
Per cose serie e' meglio usare altro.
Per carita', si puo' usare con profitto e produrre buon
software, ma bisogna essere davvero bravi e VB non ti aiuta
ad esserlo.
Ribadisco, Borland non mi paga per questo, se si vuol
programmare seriamente, usando un software che puo' fare
TUTTO quello che fa VB e TANTO ALTRO, si usi Delphi.


Delphi č utilizzabile per quasi tutto
Per la precisione: Delphi e' utilizzabile per tutto, almeno
quanto Python.


 Senza voler scatenare l'ennesima guerra di religione.....
Non preoccuparti non ho nessuna intenzione di scatenare guerre di religinone
informatica.
Siamo tra persone civili che si scambiano opinioni, consigli e conoscenze.
Tra le altre cose le mie conoscenze di Delphi e VB sono limitate a piccoli
progetti ed, evidentemente, non mi permettono di cogliere le grandi
differenze che esistenon tra questi due linguaggi/ambienti. Sicuramente il
tuo post mi da lo stimolo per approfondire le conoscenza di entrambi.
Ciao, Davide.

 quanto Python.
Umh... con Delphi si può fare web scripting?
ciao
--
Luigi
Web Site: 
http://web.tiscali.it/luigi_web
E-mail: 
cybe...@email.it
ICQ #46240443

quanto Python.
Tu conosci bene Delphi e mi pare che conosci anche Python, quali sono
i motivi che secondo te dovrebbero conviencermi ad usare Delphi (che
non conosco) e non Python (che conosco)?
-- 
Marco Barisione (ICQ 84277092)

Umh... con Delphi si può fare web scripting?
Con Delphi si puo' fare di meglio: applicazioni CGI,
Win-CGI, DLL ISAPI e NSAPI.  Delphi e' un ambiente di
programmazione, non un linguaggio.


 programmazione, non un linguaggio.
Lo so. Cmq la sintassi Python credo possa offrire di più dell'Object Pascal.
Quindi forse il paragone avrà senso quando ci sarà un RAD che usa Python
come linguaggio.


non conosco) e non Python (che conosco)?
Quello che posso dirti di Delphi e' che e' uno dei migliori
ambienti di sviluppo tuttora esistenti.  Non conoscendo
ancora Python a sufficienza, non posso fare il paragone che
mi chiedi.  E' anche probabile che nel tuo caso siano
intercambiabili.


come linguaggio.
Forse c'e' gia' ?


 Forse c'e' gia' ?
http://boa-constructor.sourceforge.net/
 magari?
È ancora presto, ma sembra a buon punto :)

È ancora presto, ma sembra a buon punto :)
Dal README.TXT di BOA:
"- Boa Constructor -
 Thanks for checking out Boa Constructor.
 Boa is supposed to be a simple Delphi for wxPython.
 [...]"
Credo non ci sia piu' niente da dire ;)


intercambiabili.
io conosco abb. Delphi, anche se putroppo non lo uso + :(, e
abb. Python e azzardo un paragone:
(spero che Alex Martelli non mi disintegri :)
- Delphi è + diffuso e su questo non ci piove
- Python è più semplice (sintassi pressochè 0..)
- Delphi è un RAD, Python NO
- Esistono tools RAD anche per Python ma il fatto è che
Python può utilizzare diverse GUI e si dovrebbe creare un
RAD per ogni GUI differente
- Delphi è proprietario, Python no (quindi perlomeno non
devo pagare :)). Beh esiste la versione Personal di Delphi
ma va bene per imparare...se non erro non ha supporto DB e
quant altro
- Python è più versatile e _scrivo_ meno codice per fare
pressochè le stesse cose...anche se in alcuni casi la
mancanza di un IDE/RAD si fa sentire...
- Python è _facilmente_ integrabile con parecchi altri
linguaggi di programmazione Python no.
speranzonso di non aver detto cavolate vi invito ad un
confronto sano e senza flames :)
un saluto da Lawrence un ex-Delphista passato a Python/C/ASM
:)
--
Lawrence "Rhymes" Oluyede
rhy...@myself.com
cosa c'entra Visual Basic 
con la programmazione?
(Antonio Cuni, PROGRAMMATORE)

programmazione, non un linguaggio.
le NSAPI sono ancora utilizzate?
cmq anche con Python+Zope puoi fare applicazioni serie web
oriented..
--
Lawrence "Rhymes" Oluyede
rhy...@myself.com


TUTTO quello che fa VB e TANTO ALTRO, si usi Delphi.
santissime parole!


 linguaggi di programmazione Python no.
Sicuro chč era questo che volevi scrivere? ;)
Ciao, Davide.

Sicuro chč era questo che volevi scrivere? ;)
no :)


 alcune delle conoscenze di Basic che già possiedi.
non credo che questa potrebbe essere una motivazione valida per usare il 
visual basic: il basic dei tempi del commodore era notevolmente diverso 
da quello visual.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 Cioe' ? sono curioso ...
In pratica, mi sembra un linguaggio sintatticamente più pulito e potente...
ad es la gestione di liste, dizionari, i cicli for che iterano su tutto...
ed anche il semplice fatto che non è tipizzato... i costrutti Python credo
offrano un risultato migliore dalla loro sinergia (ma non solo rispetto a
Object Pascal). Object Pascal, è sempre Pascal... e non ha molto di
innovativo che non abbiano altri linguaggi... cmq, magari se Alex Martelli
sta leggendo, può intervenire più incisivamente :)
ciao
Luigi

Č ancora presto, ma sembra a buon punto :)
A me non piace molto :-(
Comunque aspetto che esca qualche versione piů recente per provarlo
maggiormente.
Per QT mi pare esista qtdesigner (sempre che si chiami cosě...) che
dovrebbe funzionare anche su PYthon. Non lo ho perň mai provato.


 innovativo che non abbiano altri linguaggi... 
Object Pascal e' un dialetto del Pascal standard, che
ha aggiunto al vecchio paradigma procedurale, quello
orientato agli oggetti.  Se questo a te sembra poco !
Personalmente non volevo aprire una disquisizione comparata,
percio' non considero neanche la frase "non ha molto
di innovativo che non abbiano altri linguaggi".
Le tue affermazioni mi sembrano orientate a screditare
Object Pascal e questo non mi piace.
Non mi piace discutere con chi mi appare (bada, e' solo
un'apparenza) leggermente prevenuto.
Devo usare il termine "prevenuto", perche', scusami se
te lo dico, da cio' che affermi, mi sembra che tu Delphi 
lo conosca poco, per poterlo giudicare.
E' anche possibile che Python sia meglio di Object Pascal,
ma gradirei che a fare il confronto ci fosse qualcuno che
li conosce entrambi perfettamente ;)
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 oriented..
Difatti, io non ho mai detto il contrario.


 un saluto da Lawrence un ex-Delphista passato a Python/C/ASM
Peccato, avresti potuto essere un Delphi/Python/C/ASM-ista.


 li conosce entrambi perfettamente ;)
Non so come Alex Martelli sia messo con Object Pascal, ma visto che con
Python se la cava ( :DD altro che se se la cava!) spero possa intervenire.
Ciao!


Questa e' una cosa che a me non piace.
All'inizio non piaceva neanche a me visto che sono abituato a C/C++ ma
alla fine non ho trovato reali svantaggi provenienti dal fatto che non
è tipizzato ma ho trovato molti vantaggi.


Python se la cava ( :DD altro che se se la cava!) spero possa intervenire.
Che io sappia, Alex non conosce Delphi, ma non mi sembra il
caso invocarlo ad ogni messaggio che posti.
In quanto a Delphi, le sicurezze su quanto affermo te le
posso dare io stesso.  
Poi, e qui concludo, sei libero di pensare che Python sia
migliore.


Questa e' una cosa che a me non piace.
Beh non è vero che il Python non è tipizzato ma è meglio
dire che è debolmente tipizzato anche se il controllo sui
tipi non è cosi inesistente...


Difatti, io non ho mai detto il contrario.
si si lo so :) cmq io speravo tu rispondessi alla prima
domanda...le NSAPI si utilizzano ancora?


penso che lui intenda una cosa del genere:
<snip>
Capisco, fattibile anche in OP.


Peccato, avresti potuto essere un Delphi/Python/C/ASM-ista.
Beh il CD del Delphi Personal è sempre qui nel cassetto ;-)
e di codice Delphi ne ho ancora un bel pò.... :P


le NSAPI si utilizzano ancora?
Si', si utilizzano ancora.


win32all tutte le API Win32 e la tecnologia COM...
Mi fa piacere per Python, questa lo fanno gia' tutti gli
ambienti seri di programmazione per Windows.


Capisco, fattibile anche in OP.
con più codice però..


ambienti seri di programmazione per Windows.
infatti questo non č un obiettivo primario di Python..
anyway volevo chiarire che io sono daccordo con te....


ci giurerei...
Ripeto: non ti esprimere se non conosci.
Delphi e' integrabilissimo ad altri linguaggi.


 Non so se questo si può fare in Object Pascal con la stessa facilità
Oddio, se ti basi su questo allora anche PHP diventa un linguaggio potentissimo
:D

 posso dare io stesso.
Ok mi fido :) ma è per fare un confronto.
ciao


 > Oddio, se ti basi su questo allora anche PHP diventa un linguaggio
potentissimo :D
Si, ma in php mancano un sacco di altre cose. Io mi basavo su quei punti
solo per esempio, che magari possono essere (spesso) pecuiliarità dei
linguaggi di scripting poco tipizzati (cioè tutti :) e quindi meno probabili
in linguaggi tipo OP. Cmq se è possibile farlo anche in OP, vorrei vedere le
righe di codice :)
ciao


 iterano su tutto... ed anche il semplice fatto che non č tipizzato... i
attento, quest'ultima frase potrebbe confondere le idee a chi non 
conosce python (e infatti Andrea ha commentato "non mi piace").
In realta` non e` vero che Python non e` tipizzato (sarebbe grave): e` 
invece vero che, a differenza di C, C++, Java, C#, Pascal, Python e` un 
linguaggio tipizzato dinamicamente, che e` ben diverso dal dire che non 
e` tipizzato.


 li conosce entrambi perfettamente ;)
sto muovendo i primi passi con Python quindi non posso fare paragoni 
azzardati; pero` di certo e` *estremamente* interessante.
Cmq la piu` grossa differenza tra Python e ObjPascal e` senz'altro il 
fatto che il primo e` tipizzato dinamicamente, mentre il primo 
staticamente: questo porta a filosofie di programmazione estremamente 
differenti.


Ok mi fido :) ma è per fare un confronto.
Non voglio fare nessun confronto.


parlando con un C++-ista o con un Java-ista ;-))
A parte il fatto che nei confronti non puoi giudicare da
C++-ista o da Java-ista, devi essere imparziale, perche'
altrimenti tutto puo' apparire "grave" o tutto puo' apparire
"inutile".  Non mi puoi affatto dire che l'ereditarieta'
multipla e' una mancanza grave, tra l'altro quello che citi
e' parzialmente falso: in Delphi esistono le "interface",
che equivalgono alle classi astratte C++ e si puo' ereditare
da una o piu' di esse, cosi' come da una singola classe
reale.


molti dei più grandi programmatori, un motivo ci sarà :)
beh ci sono anche parecchi programmatori che non ne fanno
_uso_...


e` dura...
mmm meno male che so a malapena cosa siano ;-P



Senza entrare nel merito della utilita' o meno dell'ereditarieta' multipla
(ognuno ha la sua opinione) vorrei ricordare che anche Java, come Delphi,
prevede ereditarieta multipla a livello di interfacce.
Ciao, Davide.

 Non voglio fare nessun confronto.
E che parliamo a fare allora? Boh!


 e` tipizzato.
Generalmente con tipizzato si intende indicare quei linguaggi che premettono
il tipo al nome della variabile (definizione da C/C++/Java-ista :)
Ovvio che un tipo c'è sempre, infatti se fai in Python type (qualcosa) ti
stampa, pensa un pò, il tipo! :)
Forse la mia affermazione era troppo scontata o sottintendeva troppo?? :)
Ciao


E che parliamo a fare allora? Boh!
E' quello che mi chiedo anch'io.


dei punti di vista)
Se ho capito quello che intende Alex Martelli in un suo messaggio
sulla ml di Python c'è molta gente che la ritiene un errore (fra
questi Stroustrup).


 E' quello che mi chiedo anch'io.
Bene


questo in OP" piuttosto che dire: "Tze! Non mi abbasso a tanto"
Io non ho detto che non mi abbasso a tanto, ho detto che non
sono disposto a discutere con chi e' *prevenuto*, perche'
non si finirebbe piu' di tirare argomenti per contrastarsi.
Con questo ti saluto.


questi Stroustrup).
Stroustrup si dichiara totalmente pentito di "protected" in
"The Design and Evolution of C++".


 ha scritto nel messaggio
news:ul6v9uggn28vo5usc...@4ax.com...

Non ho capito.
Molta gente ritiene un errore il protected o la sua mancanza?
--
Gerolamo

Molta gente ritiene un errore il protected o la sua mancanza?
La sua presenza e tra la "molta gente", c'e' anche
l'inventore del linguaggio.


 l'inventore del linguaggio.
A dire il vero non e' che lo abbia mai usato granchč...
...ma perche' dovrebbe essere un errore l' aver inserito
il protected?
Quali svantaggi comporta?
x-post e follow up su it.comp.lang.c++
--
Gerolamo

questo in OP" piuttosto che dire: "Tze! Non mi abbasso a tanto"
ho il sospetto che tu conosca solo TP e non OP...


Forse la mia affermazione era troppo scontata o sottintendeva troppo?? :)
no era semplicemente scorretta e Antonio ti ha corretto...


 Con questo ti saluto.


> ho il sospetto che tu conosca solo TP e non OP...
Infatti sui quei punti che non conosco, speravo che Andrea rispondesse...


> no era semplicemente scorretta e Antonio ti ha corretto...
Aspetta. Scorretta era riferita alla mia affermazione sulla non tipizzazione
di Python che invece è dinamica. Io invece la sottintendevo in questa
maniera perchè indico con tipizzati i linguaggi in cui il tipo di dato è
*ben definito* con una sua bella keyword (o tipo user-defined)
ciao


 iterano su tutto...
Odio suonare come un disco rotto, ma il Javascript pareva tanto brutto? 
che è pure standard ECMA? e ha una sintassi che il parser tipico sarà 
cento righe e mezza di C? Perchè, oh, perchè lo hanno snobbato tutti? e 
io che non programmerei in nient'altro, se potessi!
(non badate a me. E' stata una lunga giornata)
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

     print elemento
for(key in dic)
 // Javascript enumera solo le chiavi, i valori li si ottiene
 // indirettamente, se necessari
 hostProvidedOutputMethod(dic[key]); 
Altra cosa bella è che anche le funzioni (e i numeri, e le stringhe, e 
i booleani) sono oggetti:
var myfunc = new Function("a", "b", "return a + b;");
myfunc(1, 2);
Non mancano le funzioni anonime:
var myfunc = function (a, b){return a * b;}
var myvar = myfunc(2, 4);


 estremamente differenti.
No, guarda, la cosa più divertente di Delphi è che ha il tipo Variant, 
con typecast automatico e facilitazioni simili, che effettivamente lo 
trasforma in un linguaggio tipizzato dinamicamente :-)))
L'unica mancanza, o meglio caratteristica irritante, di Delphi è la sua 
natura mezzo procedurale e mezzo ad oggetti. Cioè interi, stringhe, 
eccetera sono interi, stringhe, eccetera, e non oggetti. E la mancanza 
dell'overloading degli operatori. Quella sì che mi da fastidio


 reale.
stessa risposta dei Java-isti.
Qui e` questione di opinioni, ma sono fermamente convinto della grande 
utilita` dell'ereditarieta` dell'implementazione, non solo 
dell'interfaccia.


 C/C++/Java-ista :)
generalmente con "tipizzato" si intende un linguaggio in cui in ogni 
momento ad una determinata variabile e` associato un ben 
determinato tipo (definizione inventata sul momento - non credo sia 
"ufficiale").
Un linguaggio e` tipizzato staticamente se la corrispondenza 
variabile-tipo e` fissata a compile-time e non puo` cambiare; al 
contrario e` tipizzato dinamicamente quando tale corrispondeza puo` 
variare.


 questi Stroustrup).
difatti, e` per questo che ho aggiunto "a seconda dei punti di vista". 


 come Delphi, prevede ereditarieta multipla a livello di interfacce.
beh, se e` per questo l'ereditarieta` di interfaccia la offre anche il 
vecchio VB.
Personalmente ritengo molto utile l'ereditarieta` 
*dell'implementazione*; d'altronde lo scopo della OOP e` quello di 
facilitare la manutenibilita` e il riuso del codice: la presenza 
dell'ereditarieta` multipla offre al programmatore una possibilita` in 
piu` di riuso del codice.
Spesso si sente dire che l'ereditarieta` multipla e` superflua in quanto 
e` possibile "simularla" mediante aggregazione ed interfaccie; ad 
esempio in C++:
struct Interface1 {
        virtual void f() = 0;
};
struct Interface2 {
        virtual void g() = 0;
};
struct Concrete1: Interface1 {
        void f() { ... }
};
struct Concrete2: Interface2 {
        void g() { ... }
};
// ereditarieta` multipla
struct Prova: Concrete1, Concrete2
{
};
// ereditarieta` multipla simulata
struct Prova: Interface1, Interface2 {
private:
        Concrete1 c1;
        Concrete2 c2;
public:
        void f() { c1.f() }
        void g() { c2.g() }
};
In effetti non c'e` dubbio che con la seconda forma si ottengono gli 
stessi risultati della prima; ma  e` anche indubbio che la prima e` 
senz'altro la piu` flessibile e meno onerosa per il programmatore: se i 
metodo sono molti scrivere tutte le funzioni di forwarding diventa 
ripetitivo e, come ogni cosa ripetitiva, soggetta ad errori.
I PC si comportano ottimamente quando occorre svolgere dei compiti 
ripetitivi, quindi perche` non approfittarne? Il C++ (come gli altri 
linguaggi che supportano l'ereditarieta` multipla) offre esattamente 
questo.
Se ci pensate bene per l'ered. singola vale lo stesso discorso: che 
bisogno c'e` dell'ered. singola?
Essa puo` essere simulata altrettango egregiamente utilizzando la stessa 
tecnica illustrata sopra: in effetti avere una gerarchia di interfaccie 
+ aggregazione e` esattamente la stessa cosa che avere una gerarchia di 
interfaccie e implementazioni.
Ma allora perche` l'ereditarieta` singola e` supportata da tutti i 
linguaggi OO?
Essenzialmente per questioni di comodita`, produttivita`, maneggevolezza.
Ma giunti a questo punto non possiamo non chiederci perche` non 
supportare l'ereditarieta` multipla.
IMHO i linguaggi che offrono solo la singola non sono del tutto coerenti.
Ma ovviamente sono opinioni personali.
<C++-specific>
Senza considerare che in C++ l'accopiata ereditarieta` multipla+template 
consente di ottenere cose incredibili, come ad esempio le policies 
descritte da Alexandrescu in Modern C++ Design.
</C++-specific>


 Bax
Secondo me il C e poi il C++
Ciao

Infatti sui quei punti che non conosco, speravo che Andrea rispondesse...
cerca Essential Pascal sul sito 
www.marcocantu.com


Fico. E' una scopiazzatura di Javascript, a leggerlo cosě
posso farti una domanda? che centra il Javascript :) ?


dell'overloading degli operatori. Quella sě che mi da fastidio
Beh a questo punto ti consiglio di imparare il Python oppure
il C++ (se ti piace il Delphi c'č Borland C++ Builder...)
cosi non dovrai + lamentarti della mancata presenza
overloading degli operatori :)


io che non programmerei in nient'altro, se potessi!
perchè hai sta fissa con il Javascript? :)


Secondo me il C e poi il C++
secondo me sbagli a proporre questa strada...
...meglio imparare subito il secondo se il tuo obiettivo č
quello



A volte i progettisti si trovano di fronte a delle scelte che non riguardano
solamente questioni tecniche. Per esempio Java, a parte la indipendenza
dalla piattaforma del bytecode, si propone come un linguaggio piu' *pulito*
del C++ nel senso che ha eliminato tutti (o quasi) gli aspetti del C++ che,
in mano a persone poco esperte, possono essere fonti di problemi (vedi
aritmetica dei puntatori, ereditarieta' multipla, possibilita' di mescolare
binding statico e dinamico...). Ovviamente nel fare questo Sun ha dovuto
prendere delle decisione che, inevitalmente, lasciano qualcuno scontento.
Ciao, Davide.

 posso farti una domanda? che centra il Javascript :) ?
C'entra perchč ha una sintassi che a volte ricorda il Python.
(o č il contrario?!?!?=)
--
Gerolamo

dell'interfaccia.
Ok, allora spero che vorrai illustrarci la miriade di
progetti a cui hai partecipato e che hanno rafforzato la tua
certezza.  


supportare l'ereditarieta` multipla.
L'ereridarieta' multipla aggiunge poco in termini di sforzo
di implementazione/benefici, rispetto all'ereditarieta'
singola (che e' necessaria, perche' almeno una di 1 tipo ce
ne deve essere) e quindi si scende al compromesso
dell'aggregazione (che conduce agli stessi risultati).
D'altronde tutta la VCL e CLX sono scritte cosi' e
necessita' di avere un'alternativa non si e mai sentita.


e` possibile "simularla" mediante aggregazione ed interfaccie; ad 
<ITALIAN LANGUAGE ON>
Si dice "interfacce", non "interfaccie".
<ITALIAN LANGUAGE OFF>


> Fico. E' una scopiazzatura di Javascript, a leggerlo così
Peccato che JavaScript con Python possa condividere solo le "scopiazzature".
...
Credo che tu abbia sbandierato JS perchè ha una sintassi semplice come
Python. Ma il punto essenziale, è che Python è semplicità + potenza. E non
credo che JS sia un buon linguaggio da presentare come alternativa a Python
dal punto di vista della potenza :)


 variare.
Umh... domanda:
Allora C++ quando usa puntatori a oggetti è tipizzato dinamicamente?


 riciclaggio. 
python esiste da circa 15 anni se non erro. Quando e` nato Javascript?


 quello
Puo' darsi, ma penso che sia meglio prima acquisire una conoscenza sulla 
programmazione imperativa, dopodiche' se uno ne ha voglia e necissita', 
passare alla programmazione OO sia meno difficoltoso. Nel caso del C++, 
visti i legami di parentela stretti col C, mi pare buona cosa partire da 
quest'ultimo...anche se e' possibile imparare il C++ senza conoscere 
l'altro. Un po' dipende dalle necessita' e visto che si parlava di cose 
semplici, di programmi sviluppati per diletto, iniziare con il C per me 
rimane la scelta migliore.

 senza sarebbe un inferno: non e` poi cosi` fondamentale.
Strano, mi e' sembrato di leggere, in uno dei tuoi messaggi,
che sarebbe una mancanza grave.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 certezza.
non vedo come questo possa c'entrare. Cmq ho gia` spiegato la questione 
in un altro post.


 Allora C++ quando usa puntatori a oggetti è tipizzato dinamicamente?
no, anche se mi aspettavo questa domanda. Immagino che tu ti riferisca 
al polimorfismo:
class Base { };
class Derived: public Base { };
...
Base* p = new Derived;
il C++ e` a tipizzazione statica perche` il tipo di p e` Base* e da li 
non si scappa.
In effetti quando entra in gioco il polimorfismo le regole sono un po' 
meno strette; sappiamo che *p e` un oggetto di tipo Base o derivato da 
esso, ma non puo` essere nient'altro. Se ci pensi tutto cio` ha senso: 
la derivazione mi dice che Derived E`-UN Base, quindi l'oggetto puntato 
da p E`-UN Base, in ogni caso.
La tipizzazione dinamica e` un altra cosa: in Python possiamo scrivere
a = 43
a = "ciao"
a = (4,644, "ciao)
e in ogni momento il tipo di a cambia.
In genere quello che nei linguaggi statici e` ottenuto grazie al 
meccanismo di interfaccie/polimorfismo (quindi l'ereditarieta` del C++) 
nei linguaggi dinamici e` ottenuto mediante la "sostituibilita` di 
firma". Ad esempio in Python:
class Prova1:
    def f(self):
        print "Prova1.f"
class Prova2:
    def f(self):
        print "Prova2.f"
class Prova3:
    def g(self):
        print "Prova3.g"
def Func(p):
    p.f
p1 = Prova1()
p2 = Prova2()
p3 = Prova3()
Func(p1) # ok
Func(p2) # ok
Func(p3) # errore, perche` non e` possibile richiamare il metodo f su p3.
Se ci pensi bene anche il C++ supporta un meccanismo a tipizzazione 
dinamica: i template.
se vuoi una spiegazione piu` precisa ti consiglio di cercare su 
groups.google.com
 un messaggio di Alex Martelli che rispondeva ad una 
mia domanda in merito: non ricordo piu` che ng fosse (probabilmente 
it.comp.lang.c++ o it.comp.programmare).


 inevitalmente, lasciano qualcuno scontento.
si, anche qui ti do ragione; in effetti forse sono stato troppo 
avventato a bollare come "incoerenti" i linguaggi che non supportano la 
MI. IMHO essi sono incoerenti dal punto di vista dell'OO, ma occorre 
anche precisare che non sempre il pieno supporto all'OO e` una delle 
prerogative principali. Ad esempio una delle prerogative di Java e` la 
"difficolta` per farsi male" e la relativa semplicita`: da questo punto 
di vista la scelta di non includere la MI e` coerente.


utilizzare l'idioma RAII. A me pare un grave limite.
Come ti ho gia' detto: in Delphi e' possibile acquisire le
risorse nei costruttori e rilasciarle nei distruttori.  Non
vedo dove sia il problema.


IMHO essi sono incoerenti dal punto di vista dell'OO, 
Non ho mai letto da nessuna parte che la MI sia uno dei
cardini dell'OO.


 dinamica: i template.
Già


 C Language: 3.79, higher than 92% of all previous test takers.
Mi spiegheresti se ti và cosa vogliono dire queste scritte (l'inglese lo
conosco, ma non ne comprendo il senso...)?
Anthonyt

Domanda da una persona che non conosce Delphi.
Mi sembra di aver capito che in Delphi non esiste l'ereditarieta' multipla;
e' possibile simularla in altri modi?
Ti faccio questa domanda perche', IMHO, ritengo che l'ereditarieta' multipla
(dell'implementazione o solo delle interfacce) ci debba essere e stia al
programmatore utilizzarla nella maniera corretta.
Qualsiasi sistema ad oggetti puo' essere realizzato senza ricorrere
all'ereditarieta' multipla pero' questo non significa che la migliore
soluzione di un problema sia proprio quella che non la utilizza.
Ciao, Davide.

conosco, ma non ne comprendo il senso...)?
te lo spiego io
Antonio ha fatto i test presenti sul sito 
www.brainbench.com
e ha totalizzato nel C++ un punteggio di 4.73 il che lo
attesta come Master nella categoria, ciò vuol dire che
conosce piuttosto bene il C++
Nel C non è arrivato al livello di Master ma c'è andato
vicino


e' possibile simularla in altri modi?
se conosci il Java si implementa più o meno allo stesso
modo.. con l'utilizzo delle interfacce


 soluzione di un problema sia proprio quella che non la utilizza.
Non significa neanche che la migliore sia quella che la utilizza,
se e' per questo.  L'ereditarieta' multipla e' un surplus e la 
sua mancanza non e' da intendersi come un limite, se si sta parlando
di programmazione orientata agli oggetti, perche' i cardini di
quest'ultima sono i principi classici di incapsulamento/ereditarieta'/
polimorfismo.  Se poi vogliamo parlare dei "syntactic/semantic sugars" 
come l'operator overloading e l'ereditarieta' multipla, allora 
facciamolo, ma con la consapevolezza che sono solo "sugars".



Certo e' zucchero sintattico ma, IMHO, preferisco avere tale zucchero per
decidere quando addolcirmi la vita :)
Tanto e' vero che non si sta parlando se inserire l'ereditarieta' multipla
tra i cardini della OOP (perche' non e' un cardine e su questo non ci piove)
ma solamente se puo' essere utile averla a portata di mano per utilizzarla
quando essa puo' portare ad una architettura di sistema migliore (conspevole
che cio' non accade molto spesso).
Ciao, Davide :)


 necissita', passare alla programmazione OO sia meno difficoltoso. 
vero, ma Lawrence non ha mai detto di partire dall'OOP; ha detto 
semplicemente di partire dal C++ il quale, essendo un linguaggio 
multiparadigma, puo` essere benissimo utilizzato per programmare in 
maniera procedurale.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 che sarebbe una mancanza grave.
probabilmente hai letto male. Ho scritto un qualcosa del tipo "grave o 
fastidiosa, a seconda dei punti di vista", ma non ho mai specificato 
quale fosse il mio punto di vista.


che cio' non accade molto spesso).
mi inserisco un attimo nella discussione:
io non vedo il problema in questa discussione:
1 - vuoi usare l'ereditarietà multipla? fallo
2 - Delphi e Java non la supportano? La simuli con le
interfacce
a me sembra inutile un discorso sul senso della stessa
--
Lawrence "Rhymes" Oluyede
rhy...@myself.com
cosa c'entra Visual Basic 
con la programmazione?
(Antonio Cuni, PROGRAMMATORE)

 a me sembra inutile un discorso sul senso della stessa
Non posso che darti ragione al 100%; nei miei post io ho sempre e solo detto
che IMHO sia bene che ci sia e che il programmatore sia libero di fare *come
gli pare*; mi sebra che sia stato qualcun altro a tirare in ballo *i cardini
della OOP* .....
Ciao, Davide :)

 
E' vero, ma allora diciamo che se uno si orienta alla programmazione 
procedurale, come primo passo, sapere il C va bene e ti aiuta 
sicuramente al momento del passaggio al C++; oh, intendiamoci, va bene 
anche iniziare con il C++... Io preferisco partire dal C.
Ciao

anche iniziare con il C++... Io preferisco partire dal C.
Fai un pò come vuoi


 di errori difficile da trovare...
Suvvia, si scherza. Comunque è ironico avere un linguaggio che puoi 
usare allo stesso tempo come C++ o Visual Basic :-)
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!

 come alternativa a Python dal punto di vista della potenza :)
E che ne sai tu? da come parli mi sembri abbastanza ignorante in 
proposito


 posso farti una domanda? che centra il Javascript :) ?
che c'entra il Python, se č per questo :-)


 perchè hai sta fissa con il Javascript? :)
Per lo stesso motivo per cui molta gente qui sembra avere una fissa per 
il Python, credo :-) beh, e perchè penso che sia stato ingiustamente 
sottovalutato


 proposito
Senti... tu hai la minima idea della differenza abissale tra Python e
Javascript? Dimmi una cosa, potrei anche sbagliarmi ma, con JS, oltre alle
finestrelle  e giochini vari per le pagine web, che ci puoi fare?
ciao
--
Luigi
Web Site: 
http://web.tiscali.it/luigi_web
E-mail: 
cybe...@email.it
ICQ #46240443

che c'entra il Python, se è per questo :-)
ormai la discussione era confluita in un confronto OP e
Python...anche se subito troncato


usare allo stesso tempo come C++ o Visual Basic :-)
esatto Python :)


sottovalutato
io non ho la fissa per nulla, non faccio guerre di
parte...sto imparando il Python e ne sono entusiasta ma se
devo fare qlc di veloce e concreto utilizzo il Delphi. 


sottovalutato
cmq se vuoi possiamo fare un confronto tra il Javascript
(Livescript? :) e altro


 cardini dell'OO.
Non era questo che intendevo. Ho detto che sia l'ereditarieta` 
(dell'implementazione) singola che quella multipla sono puro zucchero 
sintattico che potrebbero essere sostituite con interfacce e 
aggregazione.
Alcuni linguaggi offrono il supporto solo per la singola ed e` per 
questo che mi paiono incoerenti.
Cmq, ritornando sulla tua frase, ti riporto due citazioni:
"L'assenza dell'ereditarietą multipla in Java rende impossibile il 
corretto progetto di sistemi object oriented."  (Bertrand Meyer, in una 
intervista a Pescio disponibile su 
www.eptacom.net
)
"In un linguaggio come il C++, che si basa sul 
type checking statico dell?interfaccia, l?ereditarietą multipla č 
essenziale per prevenire codice convoluto, interfacce poco sicure, o 
entrambi." (Bjarne Stroustrup, sempre intervistato da Pescio)
Il secondo e` ovviamente un giudizio di parte, ma il primo no.


 Certo... ma che centra con il nostro discorso?
e` questa la tipizzazione dinamica!


 vedo dove sia il problema.
se ho capito bene in Delphi sei costretto a scrivere codice di questo 
tipo:
var p: ^Miaclasse;
begin
        p = new( Miaclasse, Init);
        ....
        dispose(p, Destroy);
end;
e non c'e` altro modo per istanziare una classe, giusto?
Ora considera questo in C:
Miaclasse* p;
p = malloc(sizeof(Miaclasse));
p->Init();
...
p->Destroy();
free(p);
Cosa c'e` di differente tra il codice in ObjPascal e quello in C?
A me paiono uguali, ma considera che la necessita` di chiamare 
esplicitamente "costruttori" e "distruttori" e` stato uno dei motivi per 
cui e` nato il C++.
Ora considera questo:
std::auto_ptr<Miaclasse> p(new Miaclasse);
...
Quale di questi spezzoni e` il piu` facile da programmare e piu` 
difficilmente soggetto ad errori (tenendo conto anche l'eventualita` 
delle exception)?


Il secondo e` ovviamente un giudizio di parte
ma non penso che ciò influisca + di tanto...alla fine è il
creatore del linguaggio e non penso sia una persona che
parli a sproposito


>> c.f()
Come vedi i membri preceduti da "__" sono visibili dall'interno della
classe ma non dall'esterno, o meglio al di fuori della classe viene
visto come "oggetto._NomeClasse__NomeMembroPrecedutoDa2Underscore".
-- 
Marco Barisione (ICQ 84277092)

 dinamica: i template.
Io  metterei le  virgoletta intorno  a "tipizzazione  dinamica". In ogni
caso il tipo viene definito a compile time. Voglio dire, se dichiaro una
variabile di tipo vector<int> poi non  posso fare un push_back() con, ad
esempio, una stringa.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
"L'abilita` politica e` l'abilita` di prevedere quello che
 accadra` domani, la prossima settimana, il prossimo mese e
 l'anno prossimo. E di essere cosi` abili, piu` tardi,
 da spiegare  perche' non e` accaduto."

 sottovalutato
 
beh, potresti postare un messaggio su it.comp.lang con il tag 
[CONFRONTO] e vedere cosa ne salta fuori...


 sicuramente al momento del passaggio al C++; 
questo e` falso. Le possibilita` sono due:
1) il programmatore conosce *perfettamente* il C e le sue regole: in 
questo caso e` facilitato nel passare al C++
2) il programmatore conosce un po' "a naso" il C: in questo caso il 
passaggio al C++ sara` un dramma, perche` a causa della sintassi simile 
gli sembrera` di programmare in C, salvo poi dare delle facciate 
tremende quando si rende conto delle differenze sostanziali tra i due 
linguaggi.
ciao anto


 per creare script web
perfetto. Questo chiude la discussione


 che ci puoi fare? 
visto? che parli a fare?


 [CONFRONTO] e vedere cosa ne salta fuori...
Non ancora. Devo prima provare JScript.NET, non avrebbe senso parlare 
di una tecnologia rimasta ferma da anni, sarebbe come confrontare il 
vecchio Netscape con un Internet Explorer qualsiasi dal 4 in su (e c'è 
gente che ha avuto il coraggio di farlo...)
Ad esempio JScript.NET finalmente ha:
 - compilazione! al prezzo di una minima riduzione di funzionalità
 - tipizzazione esplicita delle variabili e dei valori di ritorno
 - costrutto class separato dal costrutto function
 - proprietà vere, con routine get e set
 - ereditarietà e polimorfismo (l'incapsulamento devo ancora capire
   cos'è, quindi non so se ce l'ha ;-P)
 - namespace (importazione e dichiarazione)


 - namespace (importazione e dichiarazione)
Come è esattamente l'importazione, come devo fare se voglio importare
un file? Il file importato deve avere qualche sinassi particolare al
suo interno?


> visto? che parli a fare?
Bene, illuminami, sono curioso.
Anzi, un confronto su it.comp.lang lo farei...
sottoscrivi suddetto newsgroup
Ciao


 Il secondo e` ovviamente un giudizio di parte, ma il primo no.
Mi sembra invece che il secondo giudizio sia piu` specifico e
ristretto, e come tale piu` condivisibile -- ma io lo prenderei
come troppo restrittivo, in quanto anche dove nessun check
statico e` coinvolto, le possibilita` piu` importanti date dalla
eredita` (e specificamente da quella multipla in alcuni casi),
come la Template DP, restano fondamentali.
Alex (MVP di Brainbench per il C++).

 gente che ha avuto il coraggio di farlo...)
Eh eh, io ho seguito un confronto simile, ma al tempo in cui la software
house di Netscape (si chiama Netscape?:) dormiva e si limitava a "sfoggiare"
il "grande" Netscape 4.75... se non c'era altro, con che cosa lo confronti
IE >= 4?
Ora non so JScript.NET che ha di particolare...
ci vediamo su it.comp.lang
ciao


 e` questa la tipizzazione dinamica!
Già.... ma si parlava di come essa venisse emulata in C++ tramite
polimorfismo, no.
Ciao


 parli a sproposito
infatti, e` per quello che ho messo lo stesso la citazione. Se 
Stroustrup non avesse creduto nella MI non l'avrebbe inserita nel C++. E 
non credo che BS sia un co***one...


 ad esempio, una stringa.
beh, io non ho mai sostenuto "dinamico <--> run-time" e "statico <--> 
compile-time".
Il meccanismo dei template del C++ rispecchia la definizione di 
"tipizzazione dinamica" e su questo non c'e` dubbio. Che poi in C++ 
l'intero processo avvenga a compile-time e in Python o Smalltalk avvenga 
a run-time e` un altro discorso.


 non credo che BS sia un co***one...
hola! e buona pasqua innanzitutto!
tornado a bomba a Stroustrup, ok, non sara' un co***one, ma neanche sara' un
detentore del verbo rivelato...
oppure affermi che tutti quelli che lavorano/studiando/inventano Java sono
dei co***oni? non credo! :-)
quindi (IMHO) calma con il riportare affermazioni di illuminati e dire "beh,
se l'ha scritto lui"...
... sono sempre opinioni, altrimenti si comincia a parlare di fede, e' cio'
non e' bello!
bisogna sempre mettere come ultima analisi la propria elaborazione del
problema, qualunque sia!
mo' dico la mia:
e' semplicemente una questione di costi/benefici, nient'altro. MI e' una
possibilita' data dall'OO.
ha dei cosi, ha dei benefici, non e' il verbo rivelato. si puo' applicare o
no.
C++, con il suo metodo del tipo "ti consento il max (o quasi) poi sono ca**i
tuoi",
lo mette traendone beneficio ma subendone gli "inghippi"
Java, che non vuole essere un emulo del C++, ma che vuole un linguaggio +
semplice
(a livello di "incasinamenti concettuali") non lo mette e ne paga lo scotto
della
mancanza, sopperendo ad essa mediante il meccanismo delle interfacce.
ne' uno' e' *migliore* ne' uno e' *peggiore*... si tratta solo di valutare
qual'e' piu' opportuno utilizzare
in uno specifico progetto/ambiente/modello...
ri-hola!
--
Ciao by Allanon
Q: Why do programmers always mix up Christmas and Halloween?
A: Because 25 Dec = 31 Oct

 suo interno?
Non ricordo, era sera tardi


 ci vediamo su it.comp.lang
no, grazie. Non ho nessuna fretta di perdere fiducia nel genere umano


> no, grazie. Non ho nessuna fretta di perdere fiducia nel genere umano
Addirittura!
Bah...


 e non c'e` altro modo per istanziare una classe, giusto?
no :-) stai scrivendo del codice C++ in Pascal :-) Questo vale solo per 
i puntatori generici, nemmeno per gli array dinamici (per inciso, delle 
figate :-). Si fa cosě:
var p: TMyClass;
begin
 p:= TMyClass.Create;
 // ...
 p.Free;
end;
o nel mio modo preferito, con un oggetto anonimo:
with TMyClass.Create do try
 // ...
finally
 Free;
end;


end;
L'utilizzo di with (di cui non conosco l'uso ma penso, forse a torto,
che sia all'incirca come quello di Visual Basic) non rischia di
rendere il codice più "pasticciato" se si lavora con più oggetti?


 rendere il codice più "pasticciato" se si lavora con più oggetti?
Umh... a che serve with in Pascal?


> Umh... a che serve with in Pascal?
Volevo dire in Visual Basic! :)


JavaScript 2.0. Poi, dipende dall'ambiente host.
E i nomi di variabili, funzioni e classi di "nomefile" vengono
inseriti nello scope del file che ha importato?
Uhm mi interessa questo confronto, perché non vieni su it.comp.lang?


Volevo dire in Visual Basic! :)
Quando devi utilizzare molti metodi di un oggetto e non vuoi sbatterti
continuamente a scrivere oggetto.qualcosa, cioè invece di:
Private Sub Command1_Click()
    Command1.Caption = "CIAO"
    Command1.Left = 15
    Command1.Enabled = False
End Sub
Puoi scrivere:
Private Sub Command1_Click()
    With Command1
        .Caption = "CIAO"
        .Left = 15
        .Enabled = False
    End With
End Sub


Lo immaginavo :) visto che anche in Pascal č cosě (perň per i Record).
ciao


 mi sfuggono?
Ad es il (l'unico?) vantaggio che ho spesso trovato, nasce quando nella
lettura del sorgente, non sai di che tipo è quella variabile... allora
invece di basarti su ciò che gli hai assegnato per l'ultima volta prima del
punto di codice in questione, vai a vedere il tipo.


 it.comp.lang? 
Perchè tutto quello che so su JScript 7/JavaScript 2.0/ECMAScript 4 è 
quello che ho letto sulla specifica, e le specifiche la prendono molto 
alla lontana. Come dire che non c'ho capito quasi niente :-)
Puoi dare un'occhiata qui, se ti interessa leggerlo per conto tuo:
http://www.mozilla.org/js/language/js20/


 rendere il codice più "pasticciato" se si lavora con più oggetti?
Questo lo uso solo per gli oggetti usa-e-getta, ed è raro averne più di 
uno alla volta. Comunque il try..finally lo si impara presto ad usare. 
E' la prima cosa che scrivo in un programma


 "tipizzazione dinamica" e su questo non c'e` dubbio. 
A  me  qualche   dubbio  rimane. Il  template  mi   permette  di  creare
un'astrazione, ma una  volta definito il tipo non  posso piu` cambiarlo.
Spannometricamente  quando  scrivi  std::vector<foo> a;  il  compilatore
genera  al volo  una  nuova classe  basata sul  template  ( =  modello),
diciamo vector_foo. Quando  scrivo std::vector<bar> b; viene  creata una
classe  vector_bar. Le due  classi si  basano sullo  stesso template  ma
hanno signature diverse. AFAIK a e b sono istanze di due classi diverse.
Sicuramente conosci meglio di me  il funziomanto dei template, magari mi
sfugge qualche dettaglio...
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
The trouble with computers is that they do what you tell them, 
not what you want.
D. Cohen

rendere il codice più "pasticciato" se si lavora con più oggetti?
credo di si infatti io lo uso solo quando devo inizializzare
un componente prima di crearlo a runtime o cose del genere
--
Lawrence "Rhymes" Oluyede
rhy...@myself.com

E' la prima cosa che scrivo in un programma
beh il try...finally è un costrutto per la gestione delle
eccezioni centra poco con il with :)


 - namespace (importazione e dichiarazione)
allora qui il discorso cambia...io stavo confrontando
JScript e non la versione .NET...tutti i linguaggi
supportati dalla piattaforma .NET  un pò si rivoluzionano in
primis il VB.
Anyway aspettiamo con ansia che la Borland rilasci Delphi
.NET e che l'ActiveState continui lo sviluppo di Python .NET
anche se la seconda la vedo un pò più grigia.
Sono contento che con .NET il JScript diventi a tutti gli
effetti un linguaggio di programmazione orientato agli
oggetti ma questa è ormai una caratteristica che accomuna
tutti i linguaggi .NET centrici....ecco x' sostengo che se
uno sviluppatore o meglio un team di sviluppatori debba
"abbracciare" la filosofia .NET renderà il linguaggio uno
strumento di secondo piano...JScript.NET compreso


fare molte cose in modo semplice ed elegante.
Già con la possibilità di passare un numero variabile di
parametri e con la possibilità di assegnare valori
predefiniti ai parametri si risolvono parecchie cose


mancanza, sopperendo ad essa mediante il meccanismo delle interfacce.
Ecco perchè esistono il Delphi (di Helsjberg...spero di
averlo scritto giusto) e il Python (di Van Rossum) che
uniscono semplicità (soprattutto il secondo) ad un'elevata
potenza (entrambi)
Cmq si torna ancora nel discorso riguardante la potenza
illimitata di C++ e del danno che può causare a
programmatori inesperti...cmq io nn posso andare oltre
perchè non conosco il C++ (perlomeno sono uno di quelli che
utilizza/utilizzava il C in C++..)


sono correttamente progettabili senza eredita` multipla
scusa se mi intrometto ma me ne faresti un esempio?


la illuminato dicendogli
l'ha ovviamente :)


 alcuni casi invece e` possibile.
ad esempio?


 una possibilita' data dall'OO.
[cut]
che e` esattamente quello che ho detto sino ad ora.
Ma li hai letti gli altri miei post?


 end;
che non e` poi tanto diverso da quello che ho scritto io. La differenza 
e` solo sintattica, ma il succo del discorso e` lo stesso: devi 
occuparti esplicitamente di costruire e distruggere gli oggetti: evviva, 
siamo tornati al C! 
(ci tengo a precisare che il punto esclamativo appartiene alla frase, 
non e` un accenno ad un nuovo linguaggio chiamato "C!" :-)))


 mi sfugge qualche dettaglio...
non ti sfugge nulla. Piuttosto, a me sfugge quale sia il tuo dubbio ;-))


 mi sfuggono?
beh, in un linguaggio a tipizzazione statica la dichiarazione delle 
variabili e` ovviamente indispensabile.
In quelli a tipizzazione dinamica non e` indispensabile e quindi alcuni 
linguaggi ne fanno a meno.


siamo tornati al C! 
non vedo cosa ci sia di cosi tragico nel fare ciò, forse
solo un pò di scomodità da parte del programmatore
--
Lawrence Oluyede
rhy...@myself.com

 perche` l'ha detto BS.
calma calma!
non volevo offenderti! ;-)
era che presa cosi' la frase era come dire "se lo dice S. che non e' un
co...
allora ci vuole in un buon sistema OO"... (almeno io l'ho interpretata
cosi'...)
e ho voluto puntalizzare quello che secondo me stava diventando
piu' un discorso sulla pochezza dei sistemi senza MI.
poi visto che tu sei tra quelli piu' a favore della MI, ho preso il tuo! :-)
ma senza alcun intento di polemica...
--
Ciao by Allanon
Q: Why do programmers always mix up Christmas and Halloween?
A: Because 25 Dec = 31 Oct

 "tipizzazione dinamica" e su questo non c'e` dubbio.
</quote>
Mi rimangono dubbi  sul fatto che i template  rispecchino la definizione
di tipizzazione dinamica.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
#include <stdio.h> 
int main(void) {printf("\t\t\b\b\b\b\b\b");
printf("\t\t\b\b\b\b\b\b");return 0;}

delle exception)?
Aridalle ! Non vedo che cosa c'entri: come ti ho gia' detto,
in Delphi non e' possibile implementare degli smart-pointer,
proprio perche' non c'e' allocazione statica delle istanze.
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]

rendere il codice più "pasticciato" se si lavora con più oggetti?
Non piu' di un for, while, do, etc.. etc...


siamo tornati al C! 
E gia'... peccato che in C gli oggetti non esistono !
Ti sbagli: non siamo tornati indietro, non ci siamo mai
mossi.  Non vuoi ammettere che non c'e' differenza tra
l'allocazione dinamica in C++ e Object Pascal.  Non
possedendo quest'ultimo l'allocazione statica, non e'
neanche confrontabile.  Non vedo, per l'ennesima volta, dove
sia il problema.  Il rimprovero che si puo' fare ad OP e' di
non possedere l'allocazione statica delle istanze, ma per il
resto e' *identico* agli altri linguaggi.


di tipizzazione dinamica.
Un template, in potenza, puo' lavorare su qualunque tipo di
dato.  E' questo che lo rende dinamico: non e' staticamente
legato a nessun tipo.


tra i cardini della OOP
O certo che si', se mi dici "io credo che l'ereditarieta'
multipla ci *debba* essere".  Se mi dici che e' un *dovere*
quello di implementare la MI, allora sono autorizzato a
pensare che si tratti di un aspetto fondamentale.
Chi conosce sufficientemente bene la OOP sa che non e'
cosi'.


Il secondo e` ovviamente un giudizio di parte, ma il primo no.
Ti invito a riflettere sulla frase: "in un linguaggio *come*
il C++".


 pensare che si tratti di un aspetto fondamentale.
Il fatto che una mia opinione (nei miei post abbondano i IMHO) sulla MI
venga da te letto come un dovere di implementarla mi lusinga. Nella realta'
questo e' il mio pensiero e chiunque altro e' libero di avere il proprio.
Per essere sincero, dei cardini della OOP non mi interessa niente:
Puň essere utilie la MI in alcuni progetti? SI!
E se non c'e'? Non fa niente, posso comunque fare con l'ereditarieta'
singola!
Ciao, Davide.


So che non e' importante al fine del discorso che state portando avanti ma
l'operatore -> e' previsto dall'ANSI C quindi e' legale ed eguivale a
(*p).Init()
Ciao, Davide.

 
Magari non ti aiutera' a decidere, pero' forse ti (e vi) fara' sorridere...
Ciao

Ciao
non inserire allegati please
--
Lawrence Oluyede
rhy...@myself.com

Lawrence Oluyede wrote:

Ok, scusate ma non sapevo che non si potesse...

 singola!
In questo thread si stanno confrontando dei linguaggi.
Se mi dici, "Ah ! in Object Pascal non si puo' fare, ma io ritengo
che lo si debba fare", allora mi sento in dovere di discutere di
quali siano gli aspetti fondamentali che un linguaggio 
object-oriented *debba* implementare.
Stabilito che la MI non e' tra essi, Object Pascal li implementa 
tutti.  Poi e' chiaro che ognuno si sceglie lo zucchero che gli 
piace di piu'.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 della OOP* .....
Rileggi i miei messaggi: hai perso il filo del discorso.



Ho mai detto il contrario?
Ciao, Davide.

(*p).Init()
Niente affatto.  
L'operatore -> e' previsto dall'ISO C per quanto riguarda
l'accesso ai membri delle strutture, ma i membri delle
strutture, in C, non possono essere funzioni.


Chi sei il paladino dell'OO?
No, cerco solo di fare chiarezza verso chi non conosce cio'
di cui stiamo parlando (Object Pascal).



Sei molto furbo; hai tagliato la parte piu' importante in cui dico
"(dell'implementazione o solo delle interfacce)" . OP ha MI tra interfacce
per cui, per quel che mi riguarda, e' a posto.
Ciao, Davide.


Hai perfettamente ragione, in C i metodi di una struttura non possono essere
funzioni; peccato che possano essere puntatori a funzioni e, utilizzando
l'operatore ->, si possa scrivere del codice di questo tipo:
                     Oggetto->Metodo( parametro1,......,parametroN)
dove Oggetto e' una semplice struttura e Metodo una normalissima funzione C.
Se non ci credi prova.
Ciao, Davide.

p->Init();
Se fosse come dici, si farebbe uso di un puntatore non
inizializzato (Init).
Spero che i tuoi programmi non crashino troppo spesso.


"(dell'implementazione o solo delle interfacce)" 
Veramente l'ho omessa perche' ai fini del discorso e'
assolutamente irrilevante, nessuna furbizia.
Anche con la frase tra parentesi, il senso delle tue parole
non cambia.


 inizializzato (Init).
Mi sembra chiaro che il puntatore Init vada inizializzato; Cuni non lo avra'
sottolineato per brevita' di trattazione in quanto si trattava di un esempio
concettuale.
L'idea di Cuni e' assolutamente realizzabile in C anche se il codice postato
non e' completo (non mi stupirebbe di vederti in disaccordo anche su questa
affermazione).
In ogni caso non voglio continuare questo discorso anche perche' non e'
attinente con la discussione che state portando avanti.
Ciao, Davide.


L'idea di Cuni 
L'idea di Cuni non c'entra nulla con quanto stiamo dicendo.


 legato a nessun tipo.
precisazione penso doverosa:
discorso giusto se intendi con il termine "staticamente" "a livello di
scrittura del codice",
e non "a livello di compilazione", quando invece il "tipo" del template
viene *staticamente* istanziato...
non voglio fare il preciso, ma magari a chi ha dei dubbi cosi' e'
piu' chiaro... (sempre se nn ho detto cavolate! facile, dopo 12 ore
di classi, thread e ca**i vari! :-) )


viene *staticamente* istanziato...
Ovviamente mi sto riferendo alla scrittura del codice della
classe/funzione template, ma onestamente non vedo tutta
questa ambiguita': quando si parla di "template", si parla
del momento in cui si concepisce e si scrive il modello,
perche' le istanze di un template non sono piu' modelli,
sono, appunto, istanze.


 non volevo offenderti! ;-)
non ti preoccupare, non mi sono offeso :-)
in effetti rileggendo il mio post mi sono accorto che avrei potuto 
essere un po' piu` soft, ma non era mia intenzione arrabbiarmi.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 non possedere l'allocazione statica delle istanze, 
esatto, e` proprio questo che "rimprovero". Pensavo fosse chiaro, ma 
evidentemente mi sono spiegato male.


 definizione di tipizzazione dinamica.
Ti ha gia` risposto Andrea e la mia risposta e` sostanzialmente identica.
Abbiamo detto che quando e` in gioco la tipizzazione dinamica non ci si 
basa piu` su interfacce ben definite ma piuttosto sulla "compatibilita` 
di firma". Questo e` esattamente quello che accade con i template, non 
credi?


 sorridere... Ciao
dico solo che attualmente sto effettuando la manutenzione di un grosso 
sorgente scritto da un Vero Programmatore ... :-((


sorgente scritto da un Vero Programmatore ... :-((
ahia penso che sia una delle cose più "grigie" nella
programmazione :)
--
Lawrence Oluyede
rhy...@myself.com

 linguaggi ne fanno a meno.
Esattamente come in quelli a tipizzazione statica.  Alcuni non
hanno neppure il concetto di dichiarazione, altri si`, e di
questi ultimi alcuni le considerano obbligatorie, altri no.
Prendiamo ad esempio GPL, il linguaggio di scripting proprietario
di think3 inc (detta un tempo Cad.Lab SpA).  Lo stile tipico e`
oggi quello di creare una variabile contestualmente e col tipo
appropriato, X:=3.14 per creare una variabile floating point,
senza dichiarazioni; ma facoltativamente si puo` usare una
dichiarazione VAR('X','R8') per dichiarare X come "reale di 8
byte" (floating point, double precision) poi dargli valori in
modo dinamico con X=3.14 e cosi` via.  La tipizzazione e`
comunque dinamica perche` quando X arriva come parametro ad una
funzione o procedura non e` ivi accompagnato da una dichiarazione
compile-time, bensi` l'interprete verifica dinamicamente il suo
tipo (che fa parte del descrittore della variabile, a cui
l'interprete puo`, appunto, accedere).  Questo e` un esempio di
linguaggio a tipizzazone dinamica con dichiarazioni facoltative.
Un tempo (prima che si inventasse il concetto di := in GPL) il
vecchio GPL era a tipizzazione dinamica ma con dichiarazioni
obbligatorie.  Se domani GPL abrogasse VAR e GVAR, diventerebbe
un linguaggio a tipizzazione dinamica senza dichiarazioni.
Alex

 scusa se mi intrometto ma me ne faresti un esempio?
No: leggi Meyer, "Object-Oriented Software Construction".
Sono gia` troppo indietro nella scrittura dei miei libri
per passare qualche ora a tratteggiare architetture di
sistemi sufficientemente ricchi per cadere in questo caso.
Solo un indizio: se il tuo programma deve integrarsi in
tre framework, ciascuno dei FW progettato in modo del
tutto indipendente dagli altri e tale da prevedere una
class "Application", che fai...?
Alex

 potenza (entrambi)
Python ha eredita` multipla, e mostra bene come la si puo`
ottenere (con tutta la relativa potenza) senza alcuna perdita
di semplicita` (anzi).
Alex

 ad esempio?
Ad esempio, se il tuo programma e` sufficientemente semplice (il che
non significa necessariamente PICCOLO!) da integrarsi in un solo
framework, l'eredita` multipla potrebbe essere una semplice
"comodita`" del tutto facoltativa e fungibile (cio`, ovviamente,
se il framework e` fatto per supportare questo stile:-).
Alex

class "Application", che fai...?
Probabilmente mi suicido perché è difficile che funzioni tutto
ereditando da tre classi "Application" o simili.
Avevo fatto delle prove con diversi framework ma con tutti avevo
ottenuto pessimi risultati.
-- 
Marco Barisione (ICQ 84277092)

Marco Barisione wrote:

Eppure io utilizzo regolarmente molteplici framework, tipo:
uno per GUI, uno per clienti di rete (asyncore/async_chat),
e uno custom (parte cliente di CAPS, prodotto prossimo
venturo di AB Strakt, come pure lo sara` il solo server, IFC).
Gli accrocchi per farlo senza eredita` multipla si possono
sempre trovare, ma restano accrocchi.  Con l'eredita` multipla
gestita nel modo giusto (Python 2.2, col nuovo MRO, super,
e naturalmente la semantica che in C++ viene definita come
"eredita` virtuale" ed e` + o - sempre quella desiderata)
l'integrazione e` pulita e senza drammi.
Alex

venturo di AB Strakt, come pure lo sara` il solo server, IFC).
Visto che avevi parlato di classe Application pensavo ti riferissi a
framework per gui. Farne funzionare piů di uno insieme č un incubo, č
ad esempio quasi impossibile fare il debug di un programma che usa
wxPython usando come editor PythonWin (che sa MFC).


 e` una funzione che mappa a in a.
cosa e` una "classe di tipi"? Riesco ad intuire cosa possa essere, ma 
vorrei 
esserne certo e non convincermi di cose sbagliate.
Mi sembra inoltre di capire che possiamo richiamare "chesaramai" con 
piu` di 
un tipo (basta che esso appartenga alla "famiglia" dei [Num]eri, dico 
bene?). 
Come si comporta il compilatore in questo caso? "Istanzia" piu` volte la 
funzione come avviene con i template del c++?
Altra domanda: Haskell esiste la possibilita` di definire tipi nuovi? E 
l'overload delle funzioni/operatori?
Probabilmente sono troppo deviato dal C++, ma non riesco a capire come 
il 
compilatore potrebbe inferire il tipo di una cosa del genere (in un 
miscuglio 
di C++ e quel poco che ho potuto intuire di Haskell - spero di riuscire 
ad 
essere abbastanza chiaro):
class Prova { ... };
class Prova2 { ... };
Prova2 operator+(Prova, int) {...}
chesaramai x = x+1
come si fa a stabilire il tipo del parametro e del valore di ritorno di 
"chesaramai"? Cosa restituirebbe una ipotetica "chiamata" a info 
chesaramai?


 chesaramai?
Nella typeclass Num, l'operatore `+` ha questa definizione...:
Prelude> :info +
infixl 6 +
(+) :: Num a => a -> a -> a  -- class member
Prelude>
quindi Haskell rifiuterebbe il tuo tentativo di definire un operatore
di questo nome che NON rispetta questi vincoli.  In termini di
Haskell tu hai: 
    (+) :: Prova -> int -> Prova2
ed e` chiaro che non si puo` unificare questo con:
    (+) :: a -> a -> a
se non nel caso in cui Prova == int == Prova2.
In termini C++ immagina di avere un template con un solo parametro
typename a, che definisce una funzione di signature:
        a operator+(a, a)
Ora, in C++, tu potresti definire altre funzioni con lo stesso
nome ma type-signature differente (e far fallire l'unificazione
dei template in certi casi: per unificare i template, il povero
compilatore C++ deve fare un lavoro non troppo dissimile da
quello che il compilatore Haskell, con molta meno fatica visto
che il linguaggio e` progettato apposta, fa per l'inferenza di
TUTTI i tipi...).  Ad esempio, un numero diverso di parametri
ti salverebbe.  In Haskell non ci pensi neanche: TUTTE le
funzioni hanno esattamente 1 parametro...
Come, come, ti sento chiedere -- quando scrivo x + 1 in che
senso ho un parametro solo?  La risposta fu data da Haskell
Curry, grande matematico, in cui onore si chiama appunto
Haskell questo linguaggio, e "currying" questo concetto.
Dire "una funzione f di due parametri a e b che torna c" 
equivale a dire:
"una funzione f di un parametro a; che torna una funzione
anonima di un parametro b, e quest'ultima torna c".
per questo scrivo: f a -> b -> c per descrivere f, e f a b
per chiamarla.  f a e` una funzione che prende b e torna
c.  + e` un operatore quindi lo scrivo dopo il suo unico
vero argomento e non prima, potrei farlo anche per f con lo
stropping: a `f` b e` come dire f a b.
Tutti concetti che potranno parerti alieni ma allargano la
mente e poi vengono buoni anche in tanti altri linguaggi.
Python ha imparato moltissimo da Haskell, pur essendo a
tipizzazione dinamica e multi-paradigma (non funzionale
puro, anzi purissimo, come Haskell) -- ad esempio.  Sembrano
ai poli opposti, ma dalle list comprehension al currying
agli iteratori (lazy evaluation con i baffi finti) una
modesta familiarita` con Haskell aiuta a sfruttare appieno
tutte le enormi potenzialita` di Python...:-).
Alex

 anonima di un parametro b, e quest'ultima torna c".
ok, dal punto di vista matematico mi convince; ma dal punto di vista 
sintattico? Ad esempio, se ho una funzione f che prende due parametri
        f: NxN -> N
mi pare di aver capito che Haskell la considera come
        f: N -> N^N
        f(x) ~> gx
 
        gx: N -> N
        gx(y) ~> vera_funzione(x,y)
giusto?
Quindi mi aspetterei di doverla richiamare in questo modo:
        f(3)(65)        { richiama vera_funzione(3,65) }
E` il compilatore che fa tutto questo al posto mio, vero?
E quali sono i vantaggi di un simile approccio?


 E quali sono i vantaggi di un simile approccio?
Chiarezza e limpidezza concettuale e formale.  La definizione
matematica di funzione e` una mappa da un insieme A ad un
insieme B.  Trattare le "funzioni di due argomenti", come il +,
come mappe da A allo spazio delle funzioni A->A, porta ad una
facilita` di ragionamento e manipolazione che supera di gran
lunga l'alternativa di considerarle come mappe da (AxA) ad A.
Soprattutto appena cominci a considerare funzioni di ordine
superiore come map, che da una funzione A->B te ne torna
un'altra [A]->[B] ("da lista di A a lista di B"), ecc ecc.
Alex