October 2003 - Posts
Interessante panel di discussione con questo gruppetto di esperti (in ordine da sinistra a destra nella foto):
- Anders Hejlsberg
- George Bosworth
- James Miller
- Jonathan Hawkins
- Patrick Dussud
- Chris Brumme
- Sean Trowbridge
- Brad Abrams
Tanti argomenti interessanti, riporto alcune delle cose che mi hanno più colpito.
CLR nel sistema operativo: non è una cosa di Longhorn, la si valuta più avanti... L'idea (siamo solo a questo stato) è di avere due versioni del CLR, una nel kernel (bassa latenza, utile anche per scrivere i driver!) e una "normale" per le applicazioni. Se ho capito bene, è un progetto che qualcuno in Microsoft Research sta valutando. Brad Abrams è intervenuto sull'argomento affermando che in futuro (ma non ancora in Longhorn!) il sistema operativo potrebbe essere completamente managed, affidandosi per compatibilità con Win32 a VirtualPC (immagino un VirtualPC che opera a livello di singolo processo, ergo di singola finestra di primo livello sul desktop...).
Problema di scaricare gli assembly senza tirare giù AppDomain: non è una cosa che prevedono nel breve termine, le implicazioni sono troppo grandi e ci sono troppi problemi correlati; la soluzione resta il caricamento di un assembly in AppDomain separati, con la relativa comunicazione cross-AppDomain.
Jim Miller ha ribadito le priorità che hanno, nell'ordine:
- Performances
- Security
- Features
Opinione di Anders Hejlsberg su AOP (aspect oriented programming): ok per Debug, Trace e Instrumentation, ma non va bene come sistema generico di programmazione, è difficile capire cosa sta facendo il codice, che diventa (paradossalmente!) difficile da debuggare.
Chris Brumme segnala l'esistenza un'interfaccia (unmanaged) per consultare i lock impostati sugli oggetti del CLR. Può essere utilizzata per realizzare sistemi per aiutare l'individuazione di un deadlock, ma non è un sistema da usare sistematicamente.
A mia domanda sul supporto di thread logici su fiber, Chris Brumme ha risposto che un CLR host in Whidbey può implementare controllo scheduling su Thread .NET, per esempio usando i fiber del sistema operativo. Questo è esattamente ciò che fa Yukon, ma è un sistema sconsigliato a meno di avere seri problemi di performance causati da molti thread in esecuzione in parallelo. Non viene comunque citata l'esistenza o l'idea di implementare una logica di scheduling nel CLR.
Infine, a domanda su Reflection "Perché non si può fare browse di IL da Reflection?" James Miller ha risposto "Non abbiamo avuto il tempo di farlo - potreste vedere qualcosa in futuro" (ma non ha specificato quando e in che forma).
EN
Who reads the
Chris Brumme blog could ask yourself "who is this smart guy?".
Now we have a picture: thanks Chris for your blog!
IT
Chi legge il blog di
Chris Brumme si chiede "chi è questo genio?".
Ora abbiamo una foto: Chris, grazie per il tuo blog!
La documentazione di Longhorn SDK è consultabile
on-line.
Sara Williams fa notare la presenza delle Annotations: su ogni API c'è un link a discussioni nei newsgroups e altri feed RSS (anche non Microsoft!) che forniscono informazioni, esempi, commenti (e bug??) sulla API selezionata.
L'idea è ottima, bisognerà vedere se il rapporto segnale/rumore sarà buono.
Link:
http://longhorn.msdn.microsoft.com/
.NET Framework 1.2 comprende ClickOnce, una tecnologia che vedremo quindi già a partire da Whidbey e che sarà sfruttata in modo ancora più integrato da Longhorn.
In breve, si tratta di una serie di servizi (e di classi) offerti dalle classi del Framework per distribuire applicazioni via web, gestendo anche gli aggiornamenti successivi. L'applicazione può essere effettivamente installata in locale sulla macchina, oppure può essere eseguita da remoto e poi chiusa, senza lasciare "tracce" (analogamente a come avviene adesso eseguendo un .EXE via HTTP).
Rispetto alle tecniche attuali, basate su componenti esterni al Framework, le classi fornite dal Framework offrono da una parte funzionalità più evolute, dall'altra una standardizzazione di certi comportamenti (in particolare per la security) che non sarebbe possibile ottenere con componenti esterni al Framework.
L'architettura è descritta nelle slide che si possono scaricare dal sito di
PDC, anche se vedere le demo (che ancora non ci sono sul sito) chiarisce molto meglio tutta una serie di dettagli.
L'interoperabilità possibile tra Windows Forms e Avalon è molto più grande di quanto mi aspettassi.
Grazie al fatto che è possibile "incastrare" Avalon in una finestra child, così come si può incastrare una finestra Win32 all'interno di Avalon (anche se, mi ripeto, si dovrà considerare quali sono le eventuali limitazioni di questa scelta), Windows Forms risulta perfettamente integrato con Avalon... nel senso che si possono mischiare controlli Windows Forms e Avalon a piacere.
Enfatizzare troppo questa possibilità potrebbe essere pericoloso, nel senso che potrebbe spingere qualcuno a non cercare un controllo Avalon per un'esigenza specifica ricorrendo all'uso massiccio di controlli Windows Forms in un'applicazione Avalon. E questa è una cosa sconsigliata: l'idea è di dare la possibilità di fare applicazioni che magari in Avalon sfruttano componenti di Longhorn, ma la stessa applicazione può comunque funzionare, con componenti Windows Forms, anche su versioni precedenti di Windows. Uno degli esempi fatti è quello del servizio di ricerca dei contatti di Longhorn.
Infine, la chicca è la possibilità di scrivere un'applicazione Windows Forms usando XAML, seguendo lo stesso paradigma di programmazione di Avalon. La cosa è carina e in teoria si può usare anche per programmare Windows Forms su Windows: il codice XAML genera codice C# o VB.NET... che si può "tagliare/incollare" in un progetto "tradizionale". Di per sé non è una cosa furba (non c'è ancora l'editor visuale per XAML, mentre c'è per Windows Forms), però è una possibilità che potrebbe sempre tornare utile, non si sa mai.
Esistono 4 modalità di upgrade di applicazioni Win32/MFC per Longhorn:
- Refresh (piccole modifiche per comportarsi coerentemente con l'interfaccia utente di Longhorn)
- Integrate (aggiunta di funzionalità di Longhorn al codice esistente)
- Migrate (riciclare codice esistente in un'applicazione Avalon)
- Rewrite (riscrittura completa in codice 100% verificabile, uso di sole classi WinFx, senza MFC o accesso diretto a Win32 - è l'unico modo per realizzare applicazioni eseguibili in un contesto partially trusted)
Una finestra Avalon può essere contenuta in una finestra Win32/MFC. Questo consente di integrare, in un'applicazione esistente, servizi di Avalon come la dialog box Contacts o l'Action Task Pane (quest'ultimo si comporta come finestra child).
Si può anche seguire la strada opposta, e cioè mettere una finestra Win32/MFC all'interno di una finestra Avalon (diventa una finestra child della finestra che ospita Avalon). Chiaramente in quest'ultimo caso devono esserci forti limitazioni (non si può agire all'interno di un componente Avalon che è interno alla finestra di primo livello che fa da contenitore, perché non c'è un HWND a cui agganciarsi). Per semplificare, Avalon è come una finestra Win32 che ospita all'interno un meccanismo di rendering completamente slegato da Win32 (senza messaggi, parent-child HWND e tutto il resto); all'interno di Avalon c'è un sistema grafico che non comunica con quello "esterno".
Questo spiega, in parte, perché esista ancora la coda dei messaggi e perché le applicazioni 100% Avalon abbiano, in realtà, ancora un HWND per la finestra di primo livello di un'applicazione. Questa è una scelta che devo ancora capire fino in fondo, perché dalla build attuale quest'architettura (che potrebbe anche essere solo provvisoria) è un vero punto debole (diverse volte sono riuscito a "congelare" l'interfaccia utente probabilmente per problemi proprio nella gestione della coda messaggi di Win32).
Al di là delle nuove funzionalità che Longhorn offre, il motivo per cui costituisce una "rottura" col passato è, semplicemente, una questione di compatibilità. Le applicazioni "vecchie" funzioneranno (almeno quelle Win32, non ho sentito nessuno parlare di Dos o Win16), ma le applicazioni scritte per Longhorn, anche se saranno scritte in codice managed, non funzioneranno sui sistemi operativi precedenti.
Nel 2000, con l'arrivo di .NET, abbiamo assistito a uno spostamento nel paradigma di programmazione, con un impatto relativo per l'utente finale: l'unica piattaforma su cui .NET non è supportato è Windows 95, ma da Windows 98 in poi tutte le versioni di Windows possono accogliere il Framework. Con Longhorn avremo un salto generazionale: non è solo una questione di librerie, è una questione di servizi: le applicazioni Longhorn non avranno solo una nuova interfaccia utente (Avalon), ma anche nuovi servizi (da WinFS in poi), servizi indispensabili per fornire un'esperienza diversa all'utente.
Cosa fare oggi? La cosa migliore è scrivere applicazioni in .NET, ma senza riprogettare in .NET applicazioni che oggi sono scritte con Win32 o MFC. Credo che lo stesso si possa dire per applicazioni VB6 difficili da migrare su VB.NET, per quanto in questo caso una migrazione sia qualcosa di più semplice che non portare un'applicazione MFC in Windows Forms. Se si ha un'applicazione MFC, meglio vedere da subito eventuali problemi nella ricompilazione in codice managed (non dovrebbero essercene) ma
senxa aggiungere codice Managed C++: il motivo, banale, è che con la nuova sintassi che ci sarà in Whidbey, se non c'è un motivo impellente per avere dei servizi .NET all'interno di un'applicazione MFC, meglio non esagerare, e piuttosto scrivere nuovi moduli definendo assembly in C#.
Probabilmente Microsoft non suggerirebbe qualcosa di simile, ma l'idea di avere in futuro ben 3 dialetti di C++ in un'applicazione (ANSI/ISO C++, Managed C++, il prossimo C++/CLI o come si chiamerà) non è molto allettante.
Come avevo pensato, uno dei piani è di avere un rendering di XAML (il formato di definizione dell'interfaccia utente di Avalon/Longhorn) anche per ASP.NET.
Unificazione totale, quindi...
Su MSDN si può scaricare
CLR Profiler 2.0.
Anche durante PDC esce qualcosa di nuovo!
Anders Hejlsberg presenta le novità di C# presenti in Whidbey. L'articolo che ho scritto qualche mese fa già presenta per sommi capi quello che ora si può veramente usare in Whidbey.
E' interessante notare che Hejlsberg confronta i generics di C# con i template di C++ citando la sua "visione" dei template, assimilabili a una sorta di macro risolta al momento della compilazione. Certo, la realtà non è così, ma in una sorta di semplificazione estrema è un concetto passabile...
Sempre citando le differenze, Anders fa notare come in .NET i generics sono risolti dal JIT e mantengono il controllo sui tipi, mentre in java i generics sono solo "sintactic sugar", ma si perde la possibilità di fare controllo dei tipi a runtime.
Divertente la "frecciatina" ai template C++, che richiedono uno spazio tra le parentesi angolari di chiusura per evitare ambiguità sintattiche (cosa non necessaria in C#).
C# supporta l'inferenza dei tipi, che non rende necessario specificare il tipo del template quando può essere "dedotto" dai parametri passati (a un metodo).
System.Collections.Generics è il namespace dei generics già definiti a livello di .NET Framework (sono una versione "generica" delle collection già presenti in System.Collections).
Un altro generic segnalato è
System.Nullable, che consente di aggiungere la semantica di Null a qualsiasi tipo (in genere a un tipo value).
Una cosa carina che mi era sfuggita è che, grazie all'inferenza dei tipi sui delegate, è possibile evitare avere
Thread t = new Thread( Work );
invece di
Thread t = new Thread( new ThreadStart( Work ) );
Una cosa che non c'entra niente con C# è il fatto che con Whidbey le classi per fare output sulla finestra Console prevedono dei metodi per cambiare il colore di ciò che viene scritto (estremamente comodo se si usa la finestra Console per qualsiasi motivo).
Le slide presentano anche un utile applicazione della nuova keyword
yield per creare degli enumerator (che, applicato ai generics, rendono la classe generic List molto flessibile).
Rispetto all'
articolo che avevo scritto sull'argomento "novità in C#" ci sono un po' di differenze e novità: la keyword
static sulla classe, la visibilità differenziata di getter e setter in una proprietà (uno può essere privato mentre l'altro pubblico, per esempio) e gli alias parziali di namespace (risolti con i :: e non il . per evitare ambiguità), definendo con
global il namespace globale.
Last but not least... c'è finalmente un libro su C# scritto da Anders Hejlsberg e altri... se riesco domani lo compro (con tanto di autografo!).
Il managed C++ è cambiato: non ci sono più le keyword __property, __interface, __xxx. Dunque, nuova sintassi e standardizzazione in corso.
L'obiettivo è di non fare di C++ un linguaggio di seconda categoria, ma di renderlo più integrato se non addirittura di primissima categoria, al punto di non avere un linguaggio di livello più basso in .NET (non deve esserci bisogno di ricorrere a IL, si deve poter fare qualsiasi cosa in .NET con C++). Il duplice obiettivo è di supportare caratteristiche del C++ in .NET (distruzione deterministica e template) e contemporaneamente di supportare le funzionalità di .NET in C++ (verificabilità del codice e garbage collection).
Dettagli sulla sintassi: guardate
le slide della sessione TLS310 (in generale trovate informazioni da PDC su
http://msdn.microsoft.com/events/pdc/).
In generale, la nuova sintassi è piacevole: meglio di C# per dichiarare proprietà "banali" (senza definire getter e setter, c'è un default se non ci sono operazioni da fare - vorrei veramente avere questa sintassi in C#!!).
Si può definire un distruttore (che in managed diventa un'implementazione di IDispose) e un finalizer in modo distinto (usando rispettivamente ~T() e !T() dove T è il nome del tipo) - il finalizer eventualmente definito viene chiamato solo se non è stato chiamato il distruttore (cioè Dispose). Un suggerimento è quello di usare i finalizer come tecnica di debug.
Per creare un oggetto managed la keyword è
gcnew. I puntatori managed sono definiti con ^ al posto di *. I riferimenti managed sono definiti con % invece che con &.
Molto interessante la possibilità di istanziare con
gcnew delle classi unmanaged, così come si può usare
new per un oggetto managed (i relativi proxy per la controparte managed/unmanaged sono creati dal compilatore).
Ancora, l'allocazione di un oggetto managed sullo stack implica la generazione automatica di codice che richiama il finalizer, così da fornire un meccanismo di distruzione deterministico analogo a quello degli oggetti unmanaged.
Il supporto dei template (di C++) e dei generics (del CLR) è completo: si possono usare entrambi e si possono combinare tra loro!! Questo fornisce una potenza decisamente impressionante: credo (dovrò verificarlo) che si possano usare delle librerie basate su template in C++ e riesporle (parzialmente) attraverso generics del CLR. Il punto è che i template continuano a essere risolti al momento della compilazione (da C++ a IL/nativo), mentre i generics sono risolti al momento del JIT.
Questa nuova sintassi consente anche di sfruttare l'ereditarietà multipla (a livello sintattico, per lo meno), per cui è possibile derivare una classe managed da un'altra classe managed e altre N classi unmanaged (che vengono "incapsulate" automaticamente dal compilatore come membri della classe managed).
Don Box e Chris Anderson in plenaria che scrivono software per Longhorn usando EMACS e VI: il video MediaPlayer è
scaricabile da MSDN.
Presentazione sull'SDK di Longhorn. Per cominciare studiare i namespace, l'oggetto Application, gli oggetti Elements (elementi di interfaccia utente). Sono disponibili molti esempi (per lo più in C# e VB.NET). Come già detto, tutto passa per
MsBuild, che quindi è anch'essa una delle prime utility da studiare.
Ma la demo è la parte più importante - seguono appunti presi al volo, magari non molto comprensibili. Ricordo che .XAML è il formato XML per la descrizione degli elementi di interfaccia utente di Avalon.
Tutto quello che si scrive in .XAML viene convertito in codice (C#) e compilato. Un'alternativa è quella di eseguire direttamente un .XAML all'interno di IE (va molto bene per fare prototyping, perché non si può eseguire code-behind) - ovviamente IE fa una compilazione al volo.
Il codice generato è visibile all'interno della directory OBJ\xxx (release o debug) dopo la compilazione con MsBuild. Il file di progetto generato (.proj) è compatibile con Visual Studio .NET (bisogna fare un rename in .csproj).
Nei file generati c'è un .deploy che definisce come eseguire il deployment (include anche la creazione di una cartella su Start, rendendo inutile un .MSI).
Notizia per Win32: l'attuale Platform SDK prima o poi verrà "congelato" per compatibilità col passato, e il prossimo Longhorn SDK (nome in codice
Vegas, quello "ufficiale" quando sarà rilasciato Longhorn??) sarà l'unico aggiornato e distribuito. In tale SDK avremo una nuova interfaccia utente (non ho capito se è la stessa di Whidbey) e un meccanismo di pubblicazione real-time (cache locale dei dati ma aggiornamento attraverso la rete). Questo SDK sarà costruito con tecnologia Longhorn, quindi non vedrà la luce tanto presto in questa forma "finale".
Eric Rudder ha annunciato Whidbey: non è una novità, comunque in questa nuova versione di Visual Studio vedremo le funzionalità di Edit & Continue (solo per VB) e la libreria STL.NET, che offrirà un'alternativa managed alle Standard Template Libraries (ottima cosa per chi arriva da VC++).
Uno degli obiettivi di Whidbey è quello di ridurre il numero di linee da scrivere per una soluzione complessa; questo non si applica solo ad ASP.NET, ma anche alla parte di comunicazione coi Web Service (cosa che sarà ancora migliorata con Indigo).
Non starò a descrivere le demo e le funzionalità di cui parleremo in altri articoli e che comunque saranno facilmente disponibili sul web; il senso di Whidbey è quello di voler sicuramente innovare, ma la priorità è data a quelle funzionalità che migliorano la produttività semplificando la vita al programmatore e, in una certa misura, anche nascondendo alcuni dettagli. L'idea di fondo mi sembra quella di voler rendere ancora più appetibile l'adozione di Visual Studio .NET da parte di chi non ha ancora fatto "il salto". La distanza rispetto ad ASP è sempre più alta, la distanza rispetto a VB6 è sempre più bassa - può sembrare un paradosso, ma (forse) è proprio quello che serve per convincere i più scettici.
La keynote prosegue con altre demo legate a Whidbey e si chiude con l'annuncio che Yukon e Whidbey dovrebbero essere rilasciati nella seconda metà del 2004.
More Posts
Next page »