giovedì 21 maggio 2009
Il seguente snippet:
using System;
interface IFoo {
IFoo GetInstance();
}
partial class Foo : IFoo {
public IFoo GetInstance() {
Console.WriteLine("Ciao");
return this;
}
}
class Program {
static void Main() {
(new Foo()).GetInstance().GetInstance();
}
}
stampa:
Ciao
Ciao
a console. Senza toccare lo snippet ma solo aggiungendone un pezzo, dobbiamo stampare a console:
Ciao
UGIdotNET
Ciao
martedì 14 aprile 2009
Ieri e l'altro ieri ho tenuto un corso su Sql Server 2008 Express per 80 insegnanti di informatica arrivati per l'occasione delle Olimpiadi Nazionali di Informatica (ONI2009) che quest'anno sono state ospitate proprio dalla mia citta'. E' stata un'esperienza interessante e inedita perche' parlare di un argomento cosi' "real world" davanti alle migliori menti in ambito pre-universitario vi assicuro che non e' facile. Gente eccezionale, che vive di algoritmi, grafi e C++, un po' lontana purtroppo dalle problematiche dei DB. Ieri, cioe' nel secondo giorno, mi sono dovuto inventare la successione di Fibonacci fatta in SQL...
with fibonacci(f, g) as (
select 0, 1
union all
select f + g, f + g + g
from fibonacci
where f + g < 100
)
select f
from fibonacci
union all
select g
from fibonacci
order by 1
per tenerli svegli ;-) Hanno ricevuto con interesse il compito a casa di risolvere il rompicapo delle otto regine sempre via CTE :-) Molto gradito e' stato anche l'argomento sul nuovo tipo hierarchyid perche' abbastanza vicino al loro lavoro (algoritmi, alberi, etc.). Li sono piaciuti anche i nuovi tipi geography e geometry e l'integrazione del motore con .NET, poi il lavoro con XML, etc. In ogni caso e' stato un corso abbastanza atipico, preparato in un solo sabato, dalle 2 di notte in poi, con la soddisfazione di aver conosciuto di persona quelli che preparano le nuove generazioni di informatici rumeni.
venerdì 3 aprile 2009
Sto leggendo il bellissimo libro di Dino & Andrea, "Microsoft .NET: Architecting Applications for the Enterprise" e mi ha incuriosito questa loro osservazione alla pagina 362: "[...] Microsoft Foundation Classes (MFC) offered more than a decade ago an architecture with some points in common with MVC - particularly, the Document/View (DV) model. DV can be seen as a version of MVC where the view and controller are fused together. We really don't know whether the MFC team intentionally discarded MVC to embrace DV; our feeling, however, is that DV blossomed autonomously during the design by simply applying correctly and diffusely the SoC principle".
Sembra che alla PDC del 1995, un membro del team di MFC abbia raccontato proprio la storia del "MVC versus DV" nella scelta architetturale di MFC: "[...] for the controller’s message mapping mechanism, can’t we just reuse MFC’s message map solution? Ideally, yes. But there is one big problem here... A separate controller class for message handlers may sound like a good idea, but MFC was designed in such a way that this was thought impossible. MFC allows commands such as menu picks to be rerouted to non-windows, but not windows messages such as mouse clicks. In MFC, only a CWnd can receive windows messages and only one instance of a CWnd can receive the messages for a real Windows window. Since a controller is meant to be a non-window that can handle windows messages and exist in multiple instances per window, we seem to be stuck! An interesting aside, this problem was sited by an original MFC team member as the main reason Microsoft emulated MVC for the CDocument and CView, but stopped short of implementing a controller (MFC Professional Developers Conference, 1995)". Interessante...
giovedì 26 marzo 2009
Ho scoperto una cosa a mio parere strana: un metodo (System.Web.UI.WebControls.ParameterCollection.Add(String, DbType, String)) che esiste solo nelle versioni service pack del framework .NET (2.0 SP2, 3.0 SP2, 3.5 SP1) ma non nelle versioni "normali". Mi chiedo come mai se il metodo e' stato introdotto in .NET 2.0 SP2, l'abbiano tolto dalle .NET 3.0 e .NET 3.0 SP1 per reintrodurlo nella .NET 3.0 SP2 per poi toglierlo di nuovo dalla .NET 3.5 e finalmente reintrodurlo nella .NET 3.5 SP1???...
[OT] Per i tanti amici milanesi: sono a Milano dall'8 di marzo e torno in Romania settimana prossima, probabilmente mercoledi' - se vi fa piacere magari si organizza un pranzo o una cena!
mercoledì 14 gennaio 2009
Nel suo post di ieri, "foreach l'insidioso", Luca si e' chiesto come mai il seguente snippet:
using System.Collections.Generic;
interface IPersistent { }
class Invoice : IPersistent { }
class Order : IPersistent { }
class Program {
static void Main() {
List<IPersistent> changedDocuments = new List<IPersistent>();
changedDocuments.Add(new Invoice());
changedDocuments.Add(new Order());
foreach (Invoice changedInvoice in changedDocuments) { }
}
}
compili. Secondo me, il comportamento del compilatore e' giusto, voluto e documentato. Le specifiche del linguaggio (15.8.4, ECMA-334), dicono:
"A foreach statement of the form
foreach(V v in x) embedded-statement
is then expanded to:
{
E e = ((C)(x)).GetEnumerator();
try {
V v;
while (e.MoveNext()) {
v = (V)(T)e.Current;
embedded-statement
}
}
finally {
… // Dispose e
}
}
The variable e is not visible to or accessible to the expression x or the embedded statement or any other source code of the program. The variable v is read-only in the embedded statement. If there is not an explicit conversion from T (the element type) to V (the type in the foreach statement), an error is produced and no further steps are taken."
Quindi e' la responsabilita' del programmatore quella di assicurarsi che il cast sia valido. Potremmo volere per esempio fare un foreach su tutte le Label nella ControlCollection dei Controls di una Form - sara' il nostro compito quello di "filtrare" gli elementi di tipo Label e fare il foreach soltanto su questi, oppure assicurarsi che nella Controls ci sono solo Label. Perche' il compilatore non ci aiuta? Probabilmente perche' la lista potrebbe essere costruita anche altrove!
In ogni caso, se cerchiamo un aiuto da parte dell'intellisense e del compilatore, possiamo sostituire il foreach nello snippet di Luca, con:
changedDocuments.ForEach(delegate(IPersistent persistent) { });
Sorprendemente, otteniamo anche un codice IL piu' piccolo rispetto alla variante con foreach. Il type parameter dell'argomento action del metodo ForEach, e' vincolato ora ad essere identico al type parameter della nostra List, cioe' IPersistent.
venerdì 21 novembre 2008
Salire sul palco a parlare di DSL Tools subito dopo Richard Mark Soley, Stephen J. Mellor e Michael Rosen, giuro che non e' stato facile :) Ottima l'organizzazione dell'evento, nel cinquecentesco Palazzo delle Stelline, tante discussioni interessantissime sull'MDA, modellizzazione e generazione di codice. Giornata davvero speciale!
lunedì 10 novembre 2008
Il comportamento del compilatore C#, presentato prima qui da Diego e poi nel mio post precedente, sembra singolare tra gli altri compilatori piu' conosciuti .NET. Il seguente snippet C# entra in stack overflow:
using System;
class Foo {
public virtual void Write(string s) {
Console.WriteLine("Foo virtual " + s);
}
}
class Bar : Foo {
public override void Write(string s) {
Console.WriteLine("Bar override " + s);
}
public void Write(string s, params string[] args) {
Write("Bar overload " + s);
}
}
class Program {
static void Main() {
Bar bar = new Bar();
bar.Write("Ciao!"); // Process is terminated due to StackOverflowException
}
}
mentre per gli altri linguaggi, stampa Bar override Ciao! Di seguito il codice equivalente in Visual Basic .NET, C++/CLI e Visual J#
Imports System
Class Foo
Public Overridable Sub Write(ByVal s As String)
Console.WriteLine("Foo virtual " + s)
End Sub
End Class
Class Bar : Inherits Foo
Public Overrides Sub Write(ByVal s As String)
Console.WriteLine("Bar override " + s)
End Sub
Public Overloads Sub Write(ByVal s As String, ParamArray args As String())
Write("Bar overload " + s)
End Sub
End Class
Module Program
Sub Main
Dim bar As Bar = New Bar
bar.Write("Ciao") ' stampa Bar override Ciao!
End Sub
End Module
using namespace System;
ref class Foo {
public:
virtual void Write(String^ s) {
Console::WriteLine("Foo virtual " + s);
}
};
ref class Bar : Foo {
public:
virtual void Write(String^ s) override {
Console::WriteLine("Bar override " + s);
}
void Write(String^ s, ... array<String^>^ args) {
Write("Bar overload " + s);
}
};
int main() {
Bar^ bar = gcnew Bar;
bar->Write("Ciao!"); // stampa Bar override Ciao!
};
import System.*;
class Foo {
public void Write(String s) {
Console.WriteLine("Foo virtual " + s);
}
}
class Bar extends Foo {
public void Write(String s) {
Console.WriteLine("Bar override " + s);
}
public void Write(String s, /** @attribute ParamArray() */ String[] args) {
Write("Bar overload " + s);
}
}
class Program {
public static void main(String[] args) {
Bar bar = new Bar();
bar.Write("Ciao"); // stampa Bar override Ciao!
}
}
Ho sempre considerato C# come linguaggio "centrale" di .NET, una chiave per capire meglio lo spirito della piattaforma - percio' mi meraviglio quando trovo comportamenti in C# che sono piuttosto l'eccezione anziche' la regola rispetto agli altri linguaggi .NET. A voi quale comportamento sembra piu' corretto/intuitivo?
domenica 9 novembre 2008
Questo post di Diego Martelli, fattomi notare da un amico, riesce secondo me a sorprendere un comportamento interessante di C#, ovvero il seguente snippet di codice entra in stack overflow:
using System;
class Foo {
public virtual void Write(string s) {
Console.WriteLine("Foo virtual " + s);
}
}
class Bar : Foo {
public override void Write(string s) {
Console.WriteLine("Bar override " + s);
}
public void Write(string s, params string[] args) {
Write("Bar overload " + s);
}
}
class Program {
static void Main() {
Bar bar = new Bar();
bar.Write("Ciao!");
}
}
Probabilmente molti si aspetterebbero che venisse stampato "Bar override Ciao!" a console e invece il metodo chiamato e' il Write con l'elenco variabile di parametri e non il metodo in override. Questo comportamento e' dovuto, secondo me, al fatto che abbiamo istanziato bar come:
Bar bar = new Bar();
e non come:
Foo bar = new Bar();
Il metodo Write in override nella classe Bar non fa altro che specializzare il metodo virtuale della classe base Foo, percio' perde nella gara dei metodi in overload della classe Bar perche' Write nella sua forma espansa (ECMA-334, 14.4.2.1) ha un parametro di tipo string e zero elementi nell'array di parametri.
Detto questo, ecco il mio quiz: Cosa stampa questo snippet a console?
using System;
class Foo {
public override string ToString() {
return "override ";
}
public string ToString(params string[] args) {
return "overload ";
}
}
class Program {
static void Main() {
Foo foo = new Foo();
Console.Write(foo);
Console.WriteLine(foo.ToString());
}
}
- A: override override
- B: override overload
- C: overload overload
:-)
giovedì 2 ottobre 2008
Oggi, parlando con il mio collega Daniel, e' uscita fuori una situazione interessante. Supponiamo che avete un tool che vi genera una classe partial che implementa IDisposable:
using System;
partial class Foo : IDisposable {
public void Dispose() {
Console.WriteLine("implicit");
}
}
Se volete cambiare il comportamento del Dispose senza toccare il codice generato sopra, basta implementare esplicitamente l'interfaccia IDisposable:
using System;
partial class Foo {
void IDisposable.Dispose() {
Console.WriteLine("explicit");
}
}
A questo punto uno using(Foo foo = new Foo()){} stampera' explicit a console, anziche' implicit.
domenica 14 settembre 2008
Sono tornato ieri sera dal fantastico Microsoft Community Bootcamp dove ho avuto il grande onore di essere nominato Microsoft Community Influencer, un programma locale di Microsoft Romania con cui sono state premiate un numero quasi doppio di persone rispetto al piu' conosciuto programma MVP. La gioia del riconoscimento e quella di passare due splendide giornate in compagnia di tutti i Developer Evangelist, MVP, Community Influencer e Student Partner rumeni e' stata grande quanto la sorpresa. Insieme abbiamo messo a punto un piano per un impegno piu' efficace del nostro contributo perche' la voglia di fare si vedeva negli occhi di tutti. Ringrazio i nuovi amici per avermi ricevuto nella loro famiglia e ovviamente tutti voi per avermi insegnato in tanti anni cosa vuol dire community!
lunedì 8 settembre 2008
Via questo post di Neal Ford sono arrivato a questo saggissimo wiki: 97 Things Every Software Architect Should Know. Assolutamente da non perdere! Tre dei principi li ho gia' aggiunti alla mia collezione sulla semplicita'.
[OT]: Venerdi' organizziamo il secondo workshop dello user group locale, RONUA Galati, con due presentazioni sullo stesso difficile tema: un'introduzione a DSL Tools e un'altra a VSX. Guardate quanta gente e' venuta al primo workshop, tenuto a maggio! Incredibile... Poi sono stato invitato a partecipare questo weekend insieme a tutti gli MVP e Microsoft Influencer rumeni alla quinta edizione di Microsoft Community Bootcamp, organizzata da Microsoft Romania in montagna, ottima opportunita' di conoscerci tutti insieme! Presto mettero' da qualche parte le slide e il codice del workshop e vi aggiornero' su come e' andata al bootcamp - scusate la parte off-topic del post...
martedì 15 luglio 2008
Taggato da Gianluca, ecco le mie risposte:
A quale età hai cominciato a programmare?
A 17 anni, nel lontano agosto del 1985
Come hai cominciato a programmare?
A giugno di quell'anno (23 anni fa...), avevo vinto la fase provinciale di un concorso di comunicazioni scientifiche (sezione matematica) e come premio mi avevano mandato per 2-3 settimane al 1° campo nazionale di informatica in Romania, a Câmpulung Muscel, dove ho avuto la fortuna di conoscere gli autori dei miei manuali di matematica, Gheorghe Rizescu e Octavian Stănăşilă, poi Adrian Petrescu che aveva costruito proprio il computer aMIC su cui ci insegnarono a programmare in BASIC, poi una ragazza bionda con degli enormi occhioni verdi di cui mi innamorai perdutamente ma ebbi il corraggio di dicchiararle subito il mio impossibile amore ;) Partecipai anche i prossimi anni, '86 e '87, al 2° e al 3° campo nazionale di informatica, stavolta a Târgu Mureş dove ho approfondito le mie conoscenze di BASIC ;)
Qual’è stato il tuo primo linguaggio di programmazione?
BASIC
Qual’è stato il primo programma vero che hai scritto?
Il primo "vero" programma non ricordo ma il primo programma in assoluto non lo posso scordare: ero curioso di vedere come la funzione f(x)=(1+1/x)^x tende all'infinito verso il numero di Eulero e quindi le disegnai il grafico.
Quali linguaggi hai usato da quando hai cominciato a programmare?
In ordine temporale: BASIC, FORTRAN, Turbo Pascal, C, dBase IV, Turbo Prolog, C++, Informix NewEra, Object Tcl, Delphi, Informix AppPage, JavaScript, Informix 4GL, Java, C#, VB.NET
Quando è stato il tuo primo vero lavoro da programmatore?
Direi nel 1996 (dal '92 al '96 ho fatto piu' matematica che informatica, come ricercatore)
Con il senno di poi, rifaresti lo stesso il programmatore? Ricominceresti a programmare?
Non so, probabilmente no.
Se ci fosse una cosa che hai imparato nella tua carriera e che vorresti dire ai giovani programmatori, cosa diresti?
Leggere prima la documentazione... ;)
Qual’è la cosa più divertente che hai programmato?
type foo.cs > foo.cs
csc /t:library foo.cs
Adesso è l’ora di taggare qualcun’altro...
Luca Minudel
Gian Maria Ricci
Michele Bernardi
Matteo Spreafico
lunedì 14 luglio 2008
Magari lo sanno tutti ma io ci ho perso mezz'ora per capire dove sta l'errore:
<script type="text/javascript" src="foo.js"></script>
e
<script type="text/javascript" src="foo.js" />
non sono uguali! Su IE il tag esplicito di chiusura (la prima variante) e' obbligatorio, mentre Firefox accetta tutte e due le varianti...
giovedì 5 giugno 2008
Oggi ho aperto il mio primo blog in rumeno, a questo indirizzo su RONUA. Per cominciare, ho deciso di tradurre in rumeno i post piu' interessanti che trovero' nelle varie community italiane, per far conoscere ai miei connazionali il grande spirito che ho conosciuto e mi avete regalato negli anni passati con voi. Ogni post sara' fornito ovviamente dal link al post originale, spero di avere il vostro consenso per la traduzione. E chissa', magari si stringono amicizie nuove, etc. Il blog su UGI non finisce qui, salvo completa mancanza di ispirazione :-)
mercoledì 28 maggio 2008
Carino questo modo proposto da Frank Quednau di implementare il lazy loading utilizzando l'operatore di null coalescing (ECMA-334, 14.12) e il fatto che il risultato di un'assegnazione e' il valore assegnato all'operando sinistro (ECMA-334, 14.14.1):
internal sealed class PersonProxy : Person
{
public override AddressCollection Addresses
{
get
{
return base.Addresses ?? (base.Addresses = new PersonDataMapper().GetAddressesByCode(this.Code));
}
set
{
base.Addresses = value;
}
}
}
A me sembra molto espressivo.
domenica 18 maggio 2008
Senza utilizzare stringhe, caratteri, numeri (literals) o file esterni, si chiede di scrivere un programma in C# 3.0 che stampi a console la definizione compilabile di un tipo non vuoto.
domenica 4 maggio 2008
Se vogliamo che il nostro codice giri anche su Mono, dobbiamo utilizzare:
Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "aaa.bbb")
al posto di:
AppDomain.CurrentDomain.BaseDirectory + "aaa.bbb"
perche' su Mono, BaseDirectory ritorna una stringa che non finisce in Path.DirectorySeparatorChar, mentre su CLR si'. E questo va anche in generale, quando costruiamo il path da piu' pezzi, non solo nel caso della BaseDirectory. Per esempio, chi utilizza fyiReporting RDL Project su Mono, dovrebbe modificare la riga 81 nel file Runtime/RdlEngineConfig.cs nei sorgenti del progetto e ricompilare, da:
file = dir + "RdlEngineConfig.xml";
a:
file = Path.Combine(dir, "RdlEngineConfig.xml");
perche' la stringa dir, per come e' stata costruita, su CLR finisce in Path.DirectorySeparatorChar, mentre su Mono no. In SLAR 1 alla pagina 360, Joel Marcey aggiunge questa nota sulla storia del metodo Combine:
The Combine method had an interesting ride in the standardization process. It was originally part of the Path class, then removed because it was thought to be too platform-specific, then added back because it was decided it was not any more platform-specific than any of the other methods in this class.
sabato 3 maggio 2008
Via questo post di Frans Bouma ho scoperto sotto il namespace System.Web.DynamicData.ModelProviders dell'assembly System.Web.DynamicData.dll che arriva con l'ultima release della preview di ASP.NET Dynamic Data, un'API generico composto da 4 provider per i metadata dei vari ORM (non solo Microsoft): DataModelProvider, TableProvider, ColumnProvider ed AssociationProvider. Questo unifica in buona misura le varie API che espongono i metadata degli ORM, per esempio MetaTable, MetaDataMember, MetaAssociation nel caso di LINQ to SQL, oppure quella piu' complessa dell'Entity Framework: EntitySet, EdmMember, NavigationProperty, etc. Frans ha gia' scritto un model provider per il suo LLBLGen Pro, sarebbe bellissimo averne uno anche per NHibernate. E poi mi piacerebbe in futuro vedere questa API staccata dal ASP.NET Dynamics Data con cui non dovrebbe avere tanto in comune.
mercoledì 16 aprile 2008
E' dall'anno scorso, da quando sono tornato a casa in Romania, che sogno la costituzione di una filiale locale dello user group rumeno di .NET, RONUA. Ed ecco che oggi, il presidente di RONUA, Aurelian Popa, mi incarica con l'organizzazione della nuova community. Lo spazio per gli workshop sara' messo a disposizione grazie all'entusiasmo e all'appoggio di Catalin Arama nell'attrezzatissima sala conferenze del Parco Software di Galati. Una settantina di libri personali li metto a disposizione io per creare una piccola libreria .NET (nella stanza 408 dove lavoro presso lo stesso Parco Software). Sto pensando che potrei trovare degli sponsor per pagare alloggio e trasporto fino in Romania se qualcuno di voi avra' voglia di tenere una sessione .NET qui in Romania, nella mia citta' sul Danubio, gemellata con Ancona, Brindisi, Jesi e Salerno :-) Vi terro' aggiornati sugli sviluppi della nuova community.
martedì 8 aprile 2008
Scrivete una proprieta' in cui il body del getter non contenga
return o
throw.
lunedì 17 marzo 2008
Visto l'interesse che ha suscitato l'ultimo post, ho scritto a Brad Abrams chiedendo conferma per la mia supposizione e dettagli sulla storia dell'interfaccia IValue, lui mi risponde subito indirizzandomi a Brian Grunkemeyer e stamattina trovo nella mia casella email, scritto da Brian, questo splendido pezzo della storia di .NET:
This is a good question. I was digging through the history of this file to see if I could figure out what happened, and it’s not clear. We’ve had this “hole” in the TypeCode enum since October of 2000, and I can’t find an older set of bits. But, I’m sure that comment in IConvertible is right – this used to be TimeSpan. For TimeSpan, it’s possible we thought it would be interesting for a while, then we realized that frankly not that many people need to convert a Decimal to a TimeSpan, then removed it.
You might ask why we didn’t “fix” the enum when we removed whichever of these values we had originally added. It turns out that whenever we have a breaking change internally, we need to recompile all the code that might possibly depend on the removed or changed public surface area. For us, that would mean rebuilding everything that might have referred to TypeCode.String, whose value would have changed from 18 to 17. While we do go through that process internally in DevDiv, it is costly & painful for us. Back then with some underdeveloped internal processes, it usually took 2 weeks, then even longer if your change requires a rebuilt compiler to be checked in as a new “safe” build of a compiler. Back in 2000, we were racing to ship as soon as possible (even though we didn’t ship for another year or two), so we wanted to limit churn like this. It’s sometimes easier to not deal with that level of churn in the product.
For your other question about IValue, that was the original name for IConvertible. We exposed a Variant type to match OLE Automation’s VARIANT type on the native side, for COM Interop reasons. The VB team actually was thinking that Variant should be conceptually the root of their object hierarchy (at least in terms of how types were exposed in VB 7), but that seemed a little silly. Fortunately, Anders Hejlsberg convinced them to use Object instead and we’d expose IConvertible on the base data types to allow VB users to easily change from one data type to another. So we marked Variant internal & we only use it in a handful of places internally for COM-related functionality.
Grazie ragazzi!
mercoledì 12 marzo 2008
Oggi Raf sul messenger mi chiede se conosco un modo piu' diretto per capire se un tipo sia primitivo oppure String o DateTime (questo per evitare degli if...). Pensandoci un po', arrivo a questa soluzione:
(int)Type.GetTypeCode(type) > 2
dove type e' il tipo in causa. Lui prova e mi dice che va benissimo mentre io gia' sto pensando di bloggare questa riga di codice :-) L'enum TypeCode infatti, contiene nella sua lista di valori maggiori a 2 tutti i 12 tipi primitivi piu' il DateTime e lo String, proprio quello che voleva Raf. A questo punto gli chiedo come denominare questa categoria di tipi? Primitivi non sono, built-in (ECMA-335, Partition I, 8.2.2) nemmeno, boh... fondamentali? Qui Raf si ricorda che "in una alpha erano refclass adesso non piu'". E poi fa questa osservazione giusta:
Raffaele MVP says (4:45 PM):
io comunque metterei >2 e <18
non si sa mai che aggiungano altre enum in futuro
<drian says (4:46 PM):
hai visto che manca 17?
Raffaele MVP says (4:46 PM):
non ci ho fatto caso
<drian says (4:47 PM):
in questo caso, dovrei fare anche != 17, perche' il 17 per adesso manca
e diventa un po' una schifezza
Raffaele MVP says (4:48 PM):
a questo punto puoi legarlo ad una versione specifica di quell'assembly ma poi non funziona più automaticamente
Raffaele MVP says (4:49 PM):
o ancora metterlo typesafe
>=boolean <=string
ma c'è sempre il 17 a rompere
Spulciando poi i sorgenti di Rotor, trovo questo commento nel file dell'interfaccia System.IConvertible
// The IValue interface represents an object that contains a value. This
// interface is implemented by the following types in the System namespace:
// Boolean, Char, SByte, Byte, Int16, UInt16, Int32, UInt32, Int64, UInt64,
// Single, Double, Decimal, DateTime, TimeSpan, and String. The interface may
// be implemented by other types that are to be considered values.
Cosa notate? Esattamente l'elenco di tipi che interessava Raf, nell'ordine di TypeCode e... in piu' il TimeSpan tra il DateTime = 16 e lo String = 18, cioe' corrispondente proprio al 17 che mancava! Questa interfaccia, IValue, non esiste piu' nel framework ma alcuni commenti su varie implementazioni del metodo GetTypeCode() sono rimasti come:
// IValue implementation
perche', probabilmente, conteneva questo metodo GetTypeCode. Questa ormai e' "archeologia" di .NET! :-) E non e' tutto. Guardate nei commenti dell'enum System.TypeCode:
// Note that when an object has a given TypeCode, there is no guarantee that
// the object is an instance of the corresponding System.XXX value class. For
// example, an object with the type code TypeCode.Int32 might actually be an
// instance of a nullable 32-bit integer type
Questo comportamento non e' piu' vero, perche' il valore di Type.GetTypeCode(typeof(int?)) e' TypeCode.Object, mentre il valore di Type.GetTypeCode(typeof(int)) e' TypeCode.Int32!
Dopo una discussione tecnica con Raf, direi che sia impossibile non cliccare "New Post"! :-)
martedì 4 marzo 2008
Guardando in questi giorni
Hibernate Tools, mi e' piaciuta molto l'idea che sta alla base della la sua architettura: il mapping viene rappresentato da un'istanza del
metamodello di Hibernate (classe
org.hibernate.cfg.Configuration o derivate, equivalente di
NHibernate.Cfg.Configuration) e da questo
modello vengono generati i vari artefatti tramite cosiddetti
exporter (per esempio
hbm2java,
hbm2ddl,
hbm2hbmxml, etc), che non sono altro che classi che derivano da
org.hibernate.tool.hbm2x.GenericExporter e che, insieme a dei template FreeMarker, definiscono in modo straordinariamente flessibile la parte di generazione codice/artefatti. Quindi, al posto della
POJOExporter potremmo avere, perche' no, anche una
POCOExporter per il domain model C#. Sarebbe interessante replicare in NHibernate un'infrastruttura simile, soprattutto adesso quando
la parte di generazione codice via template T4 si trova gia' inclusa in VS2008. E poi, se tutto questo viene generato da un'istanza di
Configuration, ci vuole solo un passo per creare un DSL grafico (con l'immenso aiuto di
DSL Tools) che rappresenti il mapping (N)Hibernate. E un po' quello che hanno fatto in Java con, per esempio,
Exadel Studio Pro, diventato adesso parte di
Jboss Developer Studio. Ma poi, i concetti di mapping sono quasi independenti dagli engine e quindi, perche' non pensare a un tool visuale capace di risolvere la parte mapping per piu' ORM?
lunedì 21 gennaio 2008
Lo sapevate che l'Object Relational Designer e la parte di generazione di codice per le classi LINQ to SQL in VS2008 sono state scritte utilizzando
Microsoft DSL Tools che fa parte di
VS SDK? - l'ho scoperto tramite il Reflector mentre
studiavo l'API di questo potentissimo framework che e' DSL Tools: tra le classi che derivano da
Microsoft.VisualStudio.Modeling.ModelElement, classe fondamentale per la rappresentazione degli elementi di un domain model, si trovano anche le classi internal dell'OR Designer. Questo dovrebbe dare piu' fiduccia a chi inizia o valuta di
estendere Visual Studio per un certo DSL utilizzando DSL Tools! - parti complesse del VS stesso iniziano ad essere sviluppate con questo framework.
martedì 11 dicembre 2007
Via questo post del mio connazionale Cosmin Negruseri, sono venuto a conoscenza di questa idea tanto bella quanto semplice ed efficace: proprio nella pagina Jobs di Facebook c'e' una sezione di programming puzzles belli tosti, provateli per credere. Ogni problema finisce coll'invito:
Please send your code and solutions (and a resume) to { (0xFACEB00C >> 2) in decimal format } @ facebook.com
Notate "and a resume" messo tra parentesi, per non dire dell'indirizzo email veramente originale ;) Complimenti!
(Oggi faccio gli 'anta ;) Non si scherza piu'!)