Newsgroup: it.comp.lang.delphi
Titolo: Presentazione delphi 2010

Ciao a tutti. Si, io c'ero...
Appena arrivato sono rimasto colpito..
Tanta gente, hostess in divisa (alcune molto carine..)...
Mi son detto "azz, imbarcadero fa sul serio!"...
Poi ho scoperto che c'era una manifestazione della misco... :-(((
Va be..Non si puo avere tutto.
Iniziamo dalle cose che non ci sono:
1) compilatore a 64 bit..Su questo dopo ci torno
2) interfacce che NON ereditano in modo implicito da iunknown
(aaargh!)
3) comandi vocali
Per il resto, l'ide e'  stata notevolmente potenziata.
Hanno aggiunto molte cosette che a detta di Cantu erano richieste da
anni dagli sviluppatori e che borland non ha mai risolto...
Ad esempio, oltre al magico f1 (si, quello che tanti appena si
avvicinano gli si paralizza la mano..) e' stato aggiunto il magico f6
che da accesso a delle potenti funzionalita di ricerca.
Uno dei cardini e' dato proprio dalla possibilita di cercare in dialog
o finestre che prima erano organizzate stile listbox, tipo la aggiunta
delle used ad una unit (alt+f11).
Idem dicasi per file.new...Nond evo piu ricordare sotto quale ramo o
pannello trovo thread o service application: e' stata aggiunta la
ricerca in base al test digitato stile indice help in linea, per
capirci
Ci sono poi una miriade di opzioni per configurare l'ambiente di
sviluppo....
Nella gestione degli ultimi file e progetti aperti ora si puo'  con un
colpo solo rimuovere i riferimenti non validi, ad esempio quelli
relativi a cartelle non piu valide.
ora c'e' anche spazio per gestire addon dell'ambiente ma di questo si
e' solo parlato en passant...
Il debugger permette di fare alcune cose simpatiche, come i break
point attivi in funzione del thread, la possibilita' di saltare o
ripetere l'esecuzione di alcune righe di codice NELL'AMBITO DEL METODO
ATTIVO.
Le cose toste che riguardano il linguaggio sono assai simpatiche...
Per prima cosa, e' stata introdotta una gestione completamente nuova
delle rtti.
La vecchia, come da tradizione, e' comunque supportata.
Ma la nuova non la fara' certo rimpiangere.
Possiamo dire addio a m+/m-, l'ereditarieta da tpersistent, le cose
contenute in typinfo etc etc.
La nuova gestione rtti e' praticamente indentica alla reflection
presente in java e copiata da .net.
Quindi, potete interrogare un oggetto e farvi restituire una
collection di metodi e property, ad esempio.
Con le nuove rtti, come default, TUTTO e' visibile tramite rtti.
Se volete che qualcosa non sia accessibile, occorre specificarlo.
Sono stati aggiunti anche gli attributi, che se usati nel modo giusto
possono radicalmente modificare il ns modo di fare object oriented.
Questa nuova gestione ha aperto le porte ad una cosa sui cui io stesso
ho tozzato spesso: la serializzazione.
Questa cosa, che in java esiste da sempre e che come altre cose e'
stata copiata da .net, in delphi non e' mai esistia in modo nativo.
Ora esiste.
La cosa che mi ha stupito e sulla quale invito a riflettere e' che per
serializzare non hanno usato xml ma json.
Mo magari qualcuno dice "..ma xml e' standard bla bla bla..."
Apro una parentesi:
xml e' nato per permettere a sistemi diversi di scambiarsi dati.
Questa cosa molti, l'hanno dimenticata e xml e' diventato la panacea.
json come formato viene usato da javascript ed e' molto meno pesante
di xml.
In sintesi potete prendere un istanza di una classe, serializzarla per
poi salvarla su file stream o quello che volete.
Poi, in un altro contesto, potete creare una istanza di quella stessa
classe (meglio dirlo prima che qualche furbone tenti di ricostruire
una TList partendo dalla serializzazione di una TAdoQuery...) facendo
semplicemente l'unserialize del pacchetto dati.
La serializzazione si basa pesantemente sulle nuove rtti e infatti non
include cio che voi avete esplicitamente indicato come "non
accessibile tramite rtti".
Per questa cosa voglio sottolineare che tutto sto giro se ne fotte di
public published private e protected...
E' come un sistema "parallelo" e indipendente dalla vecchia gestione
rtti.
Un altra cosa tosta e' datasnap.
Finalmente abbiamo qualcosa che fa piu' o meno quello che fa il
remoting di .net su win32 ma senza usare com, dcom, corba e anche WEB
SERVICES.
Daniele Teti ha creato in poco e niente una app console che risponde a
richieste http inviate da un client.
Questa stessa cosa puo' essere fatta anche da un normale servizio
win32.
Questa cosa ci permette quindi di creare servizi senza sbatterci,
salvo che non serva sul serio, con indy, oprte socket tcp, etc etc
etc.
Ma la cosa carina e' che questo meccanismo di comunicazione permette
al cliente di includere nella richiesta una callback che verra presa
in carico dal SERVER ma eseguita SUL CLIENT.
Ci sono dei vincoli architetturali ma niente di stratosferico: sono
vincoli di buon senso.
Inoltre, ereditando delle classi apposite, si possono mettere in piedi
legiche di encrypt/decrypt per evitare che i dati viaggino in chiaro.
Poi ci sono le gesture. Qua hanno fatto un bel lavoro, secondo me.
Ovviamente non e' cosa da usare per ogni tipo di applicazione...
Lo sviluppatore deve fare veramente poco.
In pratica, su molti degli oggetti TWInControl e' stato aggiunto
l'evento OnGesture.
A questo evento, si puo associare una taction in funzione della
gesture "disegnata" dall'utente.
Quindi, niente di cosi stratosferico.
La cosa tosta e' che esisteno gesture predefinite ma se ne possono
creare altre e gestirle.
La cosa non e' per niente difficile,
Qua si deve fare una precisazione.
Le gesture si basano su un motore.
Win7 lo includera e quindi da delphi si puo usare quello.
Attenzione: il motore non e' basato su .net, ma e' nativo win32...come
quello per il direct2d.
Si, avete letto bene: ho scritto prp WIN32.
Quindi: su win7 si potra usare il motore integrato del sistema
operativo.
Su xp, esiste un motore interno di delphi.
Il problema e' trovare dispositivi che le supportino, ma con delphi
posssiamo farlo.
Ovviamente come tutte le cose, l'uso di questo tipo di tecnologia va
PENSATO.
Il direct2d viene wrappato da un canvas specifico che fa le stesse
cose del canvas normale ma dentro fa chimate diverse che si attacccano
al motore direct2d che come quello per le gesture e' win32 e non
basato su .net
Hanno spinto molto la storia della compilazione in background sulla
quale dico "bho?!"...
L'uso delle dll permette di gestire external come se si usasse
loadlibrary.
Questo per chi usa le dll puo' essere un bel risparmio di tempo e
casini...
Sulle classi sono stati aggiunti i class constructor e desctrucotr.
Il class constructor viene chiamato prima che venga invocato per la 1a
volta il costruttore di una classe,
Questa cosa manda in pensione initialization e finalization che tanti
hanno usato in modo cinofallico...
Questo permette inoltre di evitare che il linker si porti dietro le
cose referenziate ma mai istanziate.
Questo, ihmo, in alcuni contesti puo' essere di una utilita
drammatica...
Questa e' una sintesi.
Sicuramente ho dimenticato qualcosa.
Magari se chiedete mi ricordo altro.
Ma ci sono alcune cose da dire.
Per prima cosa, gli sviluppi futuri.
Si e' parlato del compilatore a 64 bit.
Qui ho chiesto in modo spudorato "ma mo questi investono soldi per
questo sviluppo..che succede se zio billy alza il dito medio e dice
che lo sviluppo su 64 bit lo si fa solo con .net??"
La risposta e' stata che forse da vista hanno imparato che non possono
fare sempre quello che vogliono...
E anche il fatto che i motori direct2d e gesture sono nativi e
non .net e' un segnale importante.
Poi si parla di creare exe per MacOs e linux.
L'ide girerebbe comunque su windows ma potrebbe generare exe nativi
(si, nativi) per questi due os...
Questa sarebbe una botta veramente grossa, se la fanno.
Si parla di una vcl che funzioni su 3 sistemi diversi....
Alcune mie considerazioni
Sono entrato con l'idea di non andare alla devcon di Verona.
Uscendo, sono passato dal no al forse.
Per la 1a volta, delphji sembra avere quello che gli e' sempre
mancato: marketing.
Imbarcadero sembra stia ascoltando la base, pubblicizzando le cose e
facendo investimenti grossi.
Il loro obiettivo e' "delphi anywhere"...(Spero che abbiano parlato
con quelli di Sybase... rotfl)
Quindi windows, mac, linux, 64 bit.
Si tende al cloud computing, ok.
Per sviluppo multipiattaforma si usa molto java.
Sul fronte web, 
asp.net
 e' abbstanza usato.
la domanda e': esistera spazio in futuro per applicazioni c/s win32/
Win64?
Certo, ci sono cose per le quali il cloud, il web etc non vanno bene.
Si deve riflettere, ragazzi.
pax vobiscum
A.

 Ciao a tutti. Si, io c'ero...
Grande post, Alberto!
Ero dispiaciuto per non esser riuscito a partecipare, ma con il tuo 
post ï¿œ come esserci stato :-)
Ora non ho tempo per chiedere e/o commentare, magari in settimana 
sviluppiamo la discussione.
GRAZIE.
Ciao
-- 
Morde

 casini...
in sintesi, e' come se venisse fatto un late binding delle dll..
Sta poi allo sviluppatore gestire che la dll non espone la funzione
che si sta per chiamare.
Tipicamente: try..except.
A.

 Ciao a tutti. Si, io c'ero...
Purtroppo anche io non sono potuto venire e ti ringrazio per
il resoconto! Ci sono cose interessanti in pentola! Mi sembra che
stiano agendo proprio a tutto campo: non solo nuove feature per
star dietro ai capricci del mercato, ma anche migliorie delle
cose gia' presenti (debugger, dialog dell'IDE, ...).
Questo e' decisamente un buon segno!
Speriamo di vederci alla ITDevCon! :)
ciao
Giacomo

 mancato: marketing.
Mmm... secondo me, anche leggendo commenti altrove, da questo punto di 
vista si pu� sempre migliorare, per� � vero che hanno molti "dettagli" 
da recuperare per arrivare ad uno status "stabile" colmando il gap 
accumulato in anni da problemi di gestione del prodotto, dal tempo 
impiegato per la cessione di CodeGear, ecc. ecc.
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 impiegato per la cessione di CodeGear, ecc. ecc.
Marco, tra meno di zero e 0.2 e' gia un passo avanti, non trovi?
A.

 ï¿œ un perfetto esempio di serializzazione.
Ciao Marco, permettimi di puntualizzare una cosa: fermo restando che mi 
riferisco a Delphi 5/6/7. I file dfm in plain text di queste versioni 
non sono le serializzazioni dei form, ma un elenco statico degli 
attributi *non di default* di tutti i componenti vcl che lo compongono.
Per serializzazione io intendo uno stream di byte binario (che sia 
file, xml, dfm, bin, non importa) che contiene *l'immagine dell'istanza 
di un oggetto*. Questo significa che un dfm non contiene l'immagine 
dell'istanza di un form, ma la sua rappresentazione statica in funzione 
delle proprietï¿œ non di default.
Tutto questo "ambaradan" per dire che fino alle versioni da me citate 
la serializzazione di componenti non ï¿œ presente in modo nativo.
Questo articolo affronta in modo approfondito il tema della 
serializzazione per una versione da me in uso di delphi, la 5.
http://www.delphi3000.com/articles/article_2969.asp?SK=
Ciao
-- 
Morde

> Tutto questo "ambaradan"
ehm......sarebbe il fratelli di "ambaraBA"?? ;-p
A.

 delle proprietï¿œ non di default.
La serializzazione produce generalmente una "rappresentazione statica", 
quindi cosa manca al DFM per essere tale?
E' vero che le proprietï¿œ di default non vengono riportate perchï¿œ il DFM 
ha un impiego specifico, ma non credo che questa "carenza" - che 
consente comunque la ricostruzione dell'oggetto - possa comunque 
delegittimare il DFM dal ruolo di "forma di serializzazione". :)
Il formato testo si ottiene in genere dalla conversione a partire dal 
formato binario, quindi anche quest'ultima opportunitï¿œ non manca.
Io considero il DFM una forma di serializzazione a tutti gli effetti. :)


Marco Breveglieri ha scritto:

Tra l'altro nei derivati del TPersistent ci sono gia' le risorse per 
aggiungere in maniera, per loro credo abbastanza fattibile, la capacita' 
di serializzare un'istanza.
Ciao Giorgio

Ciao,
grazie intanto per l'ottima presentazione.
Faccio una domanda un pò specifica. Si è parlato di Delphi Prism? In
particolare supporta CF Net Framwork? O c'è un modo con Rad Studio
2010 di realizzare programmi per dispositivi portatili con WinCE?
Grazie anticipatamente.
Saluti.
Paolo Tarabelli

 2010 di realizzare programmi per dispositivi portatili con WinCE?
Ci sono alcuni articoli sul sito EDN (Embarcadero Developer Network) che 
spiegano come "piegare" Delphi Prism a queste esigenze, anche se non 
capisco questo stravedere per il .NET CompactFramework che in fondo 
contiene un sottoinsieme, anche abbastanza povero, dei controlli della 
libreria Windows Forms. :-)


Premetto di essere estremamente ignorante in materia ma mi è stato
chiesto di fare questa benedetta applicazione mettendomi a
disposizione solo Rad Studio 2010. Ho dato comunque un'occhiata in
giro per cercare di capire ma senza successo.
Allora faccio una domanda diretta: avendo a disposizione Rad Studio
2010 professional c'è un modo qualsiasi di compilare un programma che
possa funzionare su un dispositivo portatile con WinCE ?
Grazie a chi avesse la gentilezza e la pazienza di rispondermi.
Saluti,
Paolo

 possa funzionare su un dispositivo portatile con WinCE ?
Nein. Tutt'al pi�, con qualche escamotage, puoi cercare di ottenerlo con 
Delphi Prism (.NET), ma non si tratta comunque di una funzionalit� "out 
of the box".


Grazie per la risposta, caspita però che delusione. Ma non è molto
strano che Prism non lo faccia???
Vabbè, cercherò altre strade.
Grazie di nuovo e ciao.

Solo per dire che ho trovato finalmente della buona documentazione e
come ha giustamente segnalato Breveglieri effettivamente si può
piegare Prism a questa esigenza con qualche escmotage.
Saluti