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"! :-)
lunedì 3 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'!)
giovedì 29 novembre 2007
Stamattina, al corso che sto tenendo di architettura base, ho presentato ai ragazzi il classico pattern Decorator per servirci poi nell'implementare i vari servizi di validazione, logging, caching, etc., come decoratori di un repository, ispirato da questo post di Ayende. Uno di loro mi ha chiesto se si poteva scrivere il corpo della CreateComponent in modo ancora piu' usabile. E mi e' venuta l'idea di utilizzare un extension method generico fluente, tanto per introdurli un po' anche nel mondo di C# 3.0
Partiamo dall'implementazione standard del pattern:
using System;
public interface IComponent {
void Operation();
}
public class ConcreteComponent : IComponent {
public void Operation() {
Console.WriteLine("ConcreteComponent");
}
}
public abstract class Decorator : IComponent {
private readonly IComponent component;
protected Decorator(IComponent component) {
if (component == null) throw new ArgumentNullException("component");
this.component = component;
}
public virtual void Operation() {
this.component.Operation();
}
}
public class ConcreteDecoratorA : Decorator {
public ConcreteDecoratorA(IComponent component) : base(component) { }
public override void Operation() {
Console.WriteLine("ConcreteDecoratorA");
base.Operation();
}
}
public class ConcreteDecoratorB : Decorator {
public ConcreteDecoratorB(IComponent component) : base(component) { }
public override void Operation() {
Console.WriteLine("ConcreteDecoratorB");
base.Operation();
}
}
class Program {
public static IComponent CreateComponent() {
return
new ConcreteDecoratorB(
new ConcreteDecoratorA(
new ConcreteComponent()));
}
static void Main() {
IComponent component = CreateComponent();
component.Operation();
}
}
Questo snippet quindi stampa:
ConcreteDecoratorB
ConcreteDecoratorA
ConcreteComponent
a console. L'idea per modificare il metodo CreateComponent e' semplice: se definiamo una classe statica ComponentExtension contenente un'extension method generico come di seguito:
public static class ComponentExtension {
public static Decorator DecorateWith<T>(this IComponent component) where T : Decorator {
return (T)Activator.CreateInstance(typeof(T), component);
}
}
il metodo CreateComponent diventa:
public static IComponent CreateComponent() {
return new ConcreteComponent()
.DecorateWith<ConcreteDecoratorA>()
.DecorateWith<ConcreteDecoratorB>();
}
che, a mio parere, e' piu' espressivo. Che ne dite?
domenica 18 novembre 2007
Questo snippet (di cui manca un pezzo) si esegue in Visual Studio premendo F5 e rimane fermo al breakpoint definito nel codice del metodo Main. Muovendo poi lentamente il mouse sulla finestra dello snippet in Visual Studio, si nota che a volte viene stampato uno smiley :-) a console.
class Quiz {
// da completare
static void Main() {
System.Diagnostics.Debugger.Break(); // breakpoint
}
}
Si chiede di completare il codice che manca.
sabato 3 novembre 2007
Senza utilizzare alcun throw, completate il seguente snippet in tal modo che il catch stampi Ciao! a console e tutte e tre le inner exception devono essere di tipi diversi:
using System;
class Quiz {
// ... da completare
static void Main() {
try {
// ... da completare
}
catch (Exception e) {
if(e.InnerException != null && e.InnerException.InnerException != null && e.InnerException.InnerException.InnerException != null) {
Console.WriteLine("Ciao!");
}
}
}
}
lunedì 29 ottobre 2007
Ho notato oggi delle simmetrie tra questi due pattern: il pattern di refactoring, CollectingParameter, che accumula informazioni nell'istanza del parametro (input) e il pattern FluentInterface, che accumula informazioni nel valore di ritorno (output). Il tipo del parametro e' diverso dal tipo che contiene i metodi nel CollectingParameter, mentre il tipo del valore di ritorno e identico al tipo che contiene i metodi nel FluentInterface.
Esempi di altre simmetrie nei pattern trovate nel nostro wiki, raccolti da Luca.
lunedì 8 ottobre 2007
Due anni e mezzo fa, parlavo in questo post, di tre eventi all'interno delle classi del framework, tutti e tre nell'assembly Microsoft.VisualBasic.dll, provvisti non solo dei classici accessor add e remove, ma anche di raise (.fire in IL), accessor che non esiste ancora in C# e finivo il post chiedendomi in quale linguaggio sia stato scritto quell'assembly, Microsoft.VisualBasic.dll.
E oggi scopro che C++/CLI (ECMA-372, 19.6.2) mette a disposizione tre accessor anziche' due: add, remove e raise. Quindi, lo snippet del mio vecchio post, diventa in C++/CLI:
delegate void FooFiredEvent();
ref class Foo {
FooFiredEvent^ m_FooFired;
public: event FooFiredEvent^ FooFired {
void add(FooFiredEvent^ value) {
m_FooFired += value;
}
void remove(FooFiredEvent^ value) {
m_FooFired -= value;
}
void raise() {
if(m_FooFired) {
m_FooFired();
}
}
}
};