kodehoved

Efter en længere pause som følge af en svær lungebetændelse, fortsætter jeg her med fjerde indlæg i min serie om nyhederne i C# 4.

I de foregående indlæg har vi set på motivationen for dynamiske typer, eksempler på brug af dynamiske typer og den underliggende infrastruktur for dynamiske typer. I dette indlæg er vi kommet til to nye, dynamiske typer i .NET 4, ExpandoObject og DynamicObject.

ExpandoObject

ExpandoObject er en type, der tillader, at vi kan modificere egenskaberne for konkrete instanser. Opretter vi en dynamisk instans af ExpandoObject, kan vi således tilføje properties, metoder og så videre til denne. Her er et eksempel, hvor vi tilføjer en property ved navn Text:

dynamic expando = new ExpandoObject();
expando.Text = "hello world";

Herefter kan vi tilgå denne property på instansen på almindelig vis, og ganske som forventet udskriver nedenstående teksten hello world.

Console.WriteLine(expando.Text);

Denne egenskab gør, at vi kan skrive kode, der i nogle tilfælde bliver betydelig mindre omfattende, end vi er vant til. Lad os se på et eksempel.

Når vi arbejder med XML, er konstruktioner som nedenstående hyppige:

var movie = new XElement("Movie",
   new XElement("Title", "Blade Runner"),
   new XElement("Release", "1982"),
   new XElement("Cast",
      new XElement("Actor", "Harrison Ford"),
      new XElement("SupportingActor", "Rugter Hauer"),
      new XElement("Actress", "Sean Young"),
      new XElement("SupportingActress", "Daryl Hannah")
   )
);

Console.WriteLine((string)movie.Element("Cast").Element("Actor"));

Ved hjælp af Element(), kan vi udvælge specifikke dele af vores XElement-struktur. Dette er blot en af flere varianter over samme tema, men de fleste af dem fungerer ved, at vi bruger tekst til at navigere rundt i strukturen. I de tilfælde er brugen af dynamiske typer oplagt.

Ved hjælp af ExpandoObject, kan vi erklære en tilsvarende struktur således:

dynamic movie = new ExpandoObject();
movie.Title = "Blade Runner";
movie.Release = "1982";
movie.Cast = new ExpandoObject();
movie.Cast.Actor = "Harrison Ford";
movie.Cast.SupportingActor = "Rutger Hauer";
movie.Cast.Actres = "Sean Young";
movie.Cast.SupportingActres = "Daryl Hannah";

Fordi vores instans af ExpandoObject tilpasser sig det konkrete behov, kan vi blot tilføje egenskaber til objektet efter behov. Brugen ligner til forveksling den kode, vi ville skrive, hvis vi havde en eksplicit type til håndtering af vores film, men vi har ikke skrevet kode til erklæring af denne type.

Tilgang til dele af objektet ligner ligeledes den kode, vi ville skrive, hvis vi havde en eksplicit type:

Console.WriteLine(movie.Cast.Actor);

Bemærk at som jeg også var inde på i forrige indlæg, er det vigtigt, at instansen erklæres med typen dynamic, da det er denne angivelse, der tillader ExpandoObject at redefinere sig selv efter behov. Havde vi erklæret movie af typen ExpandoObject, havde vi fået en instans med denne statiske type, og dermed afskåret os selv mulighederne for at definere opførslen ved hjælp af det dynamiske metaobjekt.

Lad os udbygge eksemplet lidt. Hvordan ville det se ud, hvis vi havde brug for en samling af film-objekter baseret på ExpandoObject? Her er et bud:

var movies = new List<dynamic>();

movies.Add(new ExpandoObject());
movies[0].Title = "Blade Runner";
movies[0].Release = 1982;

movies.Add(new ExpandoObject());
movies[1].Title = "Alien";
movies[1].Release = 1979;

dynamic movie = new ExpandoObject();
movie.Title =  "Delicatessen";
movie.Release = 1991;
movies.Add(movie);

Ikke mange overraskelser her og ganske som forventet, kan vi bruge LINQ på vores samling af film:

var movies80 = from m in movies
               where m.Release >= 1980 &amp;amp;amp;amp;amp;amp;&amp;amp;amp;amp;amp;amp; m.Release < 1990
               select m.Title;

foreach(var m in movies80) {
    Console.WriteLine(m);
}

Som det fremgår, tilbyder ExpandoObject en simplere syntaks for eksemplerne i dette tilfælde. Performance er i begge tilfælde begrænset af de dynamiske opslag, så her adskiller brugen af ExpandoObject sig hverken i positiv eller negativ retning. Det er selvfølgelig værd at understrege, at syntaks ikke er alt, og hvis vi har en rig datamodel i koden, er vi bedre tjent med statiske typer, men ExpandoObject tilbyder et interessant alternativ i specifikke situationer.

DynamicObject

DynamicObject tilbyder langt hen ad vejen den funktionalitet, vi så implementeret via IDynamicMetaObjectProvider i forrige indlæg. Det interessante ved DynamicObject er, at den fritager os for en del af arbejdet med implementering af dette interface ved at udstille et sæt virtuelle metoder, vi kan overstyre efter behov for at få lignende funktionalitet.

Har vi behov for en type, hvor vi kan omdefinere hele eller en del af den gængse opførsel, kan vi således med fordel gøre dette ved at lave en specialisering af DynamicObject.

Den åbenlyse begrænsning ved DynamicObject er, at at vi kun kan bruge den, hvis vi ikke har brug for yderligere specialiseringer. Skal vores type ligeledes arve fra en anden type, er vi nødt til at gå den slagne vej og implementere IDynamicMetaObjectProvider selv. I de resterende tilfælde kan vi med fordel gøre brug af DynamicObjects implementering.

Lad os se på et eksempel.

public sealed class DynamicType : DynamicObject {
   public override bool TryInvokeMember(
      InvokeMemberBinder binder,
      object[] args, out object result) {

      result = null;

      Console.WriteLine("Calling the method {0}", binder.Name);
      return true;
   }
}

Ovenstående type overstyrer TryInvokeMember(), hvilket vil sige, at hver gang, vi kalder en metode på en instans af denne type, vil vi få kaldt ovenstående. Vi kan derfor erklære en dynamisk instans og kalde et antal ikke-eksisterende metoder således:

dynamic d = new DynamicType();

d.Boing();
d.Boom();
d.Tschak();

Resultatet er udskriften Calling the method Boing, Calling the method Boom og Calling the method Tschak. Det er selvfølgelig ikke særlig brugbart i sig selv, men det illustrerer, hvordan vi kan redefinere, hvad det vil sige, at kalde metoder på en instans af denne type.

For et øjeblik siden påstod jeg, at TryInvokeMember() bliver kaldt hver gang, vi kalder en metode på en instans af vores type. Det er ikke helt korrekt. Havde det været korrekt, ville vi kunne implementere eksemplet fra forrige indlæg via DynamicObject, men det kan vi ikke. Kalder vi en metode, der findes på typen, bliver denne kaldt. Så hvis vi eksempelvis gør følgende:

Console.WriteLine(d.GetType());

Får vi udskriften NewsInCS4.DynamicType og ikke Calling the method GetType, som man ellers kunne tro.

Det skyldes, at DynamicObject først undersøger, om en given metode er tilgængelig via objektets statiske type. Så hvis vi kalder en eksisterende metode, kommer TryInvokeMember() ikke ind i billedet, og derfor kan vi ikke bruge DynamicObject til at implementere en type, hvor der er byttet om på to metoder.

DynamicObject tilbyder således stort set de samme muligheder, som hvis vi selv implementerer IDynamicMetaObjectProvider, men da den fritager os for en del af implementeringsarbejdet, vil det i mange tilfælde være lettere at lave en specialisering af DynamicObject end at skulle implementere IDynamicMetaObjectProvider.

Dette er tredje indlæg i en serie om nyhederne i C#. Foregående indlæg er her og her.

I forrige indlæg antydede jeg, at dynamic tilbyder større fleksibilitet end Reflection, og det skal vi se på i dette indlæg.

Sammen med C#s nye dynamic nøgleord er der ligeledes kommet nogle udvidelser til klassebiblioteket og afviklingsmiljøet for at understøtte de dynamiske egenskaber. Formålet er at understøtte et koncept, Microsoft har kaldt ”The Object is King”. Ideen er at introducere en abstraktion for, hvad det vil sige, at gøre noget på et objekt. Centralt i denne sammenhæng er det nye interface IDynamicMetaObjectProvider.

Hvis en type implementerer dette interface, betyder det, at typen selv håndterer, hvad det vil sige, at udføre forskellige operationer på instanser af typen. Mere specifikt betyder det, at typen kan returnere en instans af DynamicMetaObject, og det er denne instans, der står for nævnte funktionalitet. Ved at overstyre metoder i DynamicMetaObject, kan vi således definere objektets eksakte grundopførsel.

Lad os se på et eksempel, men lad os først få et par aspekter omkring statiske typer på plads. Betragt nedenstående metode:

public void SomeMethod(SomeType instance) {
   instance.Method();
}

Hvad sker der her? Som udgangspunkt får vi kaldt Method på en instans af typen SomeType. Hvis SomeType er en referencetype, Method er virtual, og det aktuelle objekt, instance peger på, er af en specialisering af SomeType, kan vi få kaldt en variant af Method. I begge tilfælde kan vi dog på oversættelsestidspunktet generere den specifikke kode, fordi C#s typebinding dikterer, hvad der skal ske her. ⁽¹⁾

Lad os nu forestille os, at vi flytter den handling der afgør, at vi kalder Method fra SomeType fra oversættelsestidspunktet til afviklingstidspunktet. Hvis metoden var erklæret som void SomeMethod(dynamic instance) ville det være præcis det, der ville ske, men lad os gå et skridt videre.

Lad os ydermere forestille os, at selve afgørelsen omkring, hvad det vil sige, at kalde en metode er blevet uddelegeret. I så fald er det ikke længere C#s statiske typesystem, der afgør, at effekten af instance.Method() er at kalde koden på SomeType associeret med Method(). I stedet kan vi implementere præcis den opførsel, vi har brug for. Det er, hvad IDynamicMetaObjectProvider tillader os.

Lad os se på et eksempel. Betragt nedenstående klasse:

public sealed class WeirdType : IDynamicMetaObjectProvider {
   public void Foo() {
      Console.WriteLine("Foo");
   }

   public void Bar() {
      Console.WriteLine("Bar");
   }

   public DynamicMetaObject GetMetaObject(Expression parameter) {
      return new WeirdTypeMetaObject(parameter, this);
   }
}

WeirdType har to simple metoder, Foo og Bar, der henholdsvis udskriver teksterne ”Foo” og ”Bar”. Kalder vi dem som følger, får vi helt som forventet udskriften: Foo efterfulgt af Bar.

var wt = new WeirdType();
wt.Foo();
wt.Bar();

(Husk var blot betyder, at compileren sætter typen af wt til den type, den kan udlede af tildelingen – altså WeirdType. Der er ikke noget magi, og det er ikke farligt.)

Derudover implementerer WeirdType IDynamicMetaObjectProvider og har derfor metoden GetMetaObject, som returnerer en instans af WeirdTypeMetaObject. Det betyder, at hvis vi kalder metoder på en dynamisk erklæret instans, vil det være opførelsen i det returnerede metaobjekt, der definerer den tilhørende funktionalitet. Det er lidt af en mundfuld, så lad mig prøve at konkretisere.

Som et illustrativt eksempel kunne vi få metaobjektet til at bytte om på metoderne, så når vi kalder Foo(), afvikles koden for Bar() og omvendt. For at gøre dette, skal vi implementere den nødvendige logik i WeirdTypeMetaObject.

Ændrer vi således ovenstående eksempel fra var til dynamic, vil compileren vide, at den er nødt til at overlade håndteringen af wt til afviklingsmiljøet, og eftersom typen implementerer IDynamicMetaObjectProvider, ved afviklingsmiljøet, at den aktuelle opførsel for instansen er defineret af vores metaobjekt.

For at gøre en lang historie kort: Kører vi nedenstående, får vi udskriften Bar efterfulgt af Foo, fordi vi har redefineret, hvad det vil sige, at kalde metoder på objektet.

dynamic wt = new WeirdType();
wt.Foo();
wt.Bar();

Eksemplet er selvsagt ikke det mest brugbare, men det illustrerer to vigtige pointer:

For det første viser det, at der kan gælde helt andre regler for, hvad det vil sige, at udføre operationer på en instans, når referencen til denne er erklæret som dynamic.

For det andet illustrerer det, at vi kan implementere regler, der ændrer de grundlæggende spilleregler fundamentalt. Det er en stærk feature, der kan åbne nogle døre i specielle situationer, men det er selvfølgelig også noget, der bør bruges med omtanke.

Definitionen af WeirdTypeMetaObject ser ud som følger:

public class WeirdTypeMetaObject : DynamicMetaObject {
   public WeirdTypeMetaObject(Expression expression, WeirdType value)
      : base(expression, BindingRestrictions.Empty, value) {}

   public override DynamicMetaObject BindInvokeMember(
      InvokeMemberBinder binder, DynamicMetaObject[] args) {

      Action action;

      if (binder.Name == "Bar") {
         action = new Action(((WeirdType) Value).Foo);
      } else if (binder.Name == "Foo") {
         action = new Action(((WeirdType) Value).Bar);
      } else {
         return base.BindInvokeMember(binder, args);
      }

      return new DynamicMetaObject(
         Expression.Block(
            Expression.Call(Expression.Constant(Value), action.Method),
            Expression.Default(typeof(object))
         ),
         BindingRestrictions.GetInstanceRestriction(Expression, Value),
         Value
      );
   }
}

Jeg vil ikke komme ind på detaljerne i ovenstående i dette indlæg, men jeg skal nok vende tilbage til det senere, da der er mindst en overraskelse, der kan drille lidt.

Ved at implementere IDynamicMetaObjectProvider får vi komplet kontrol over en types basale semantik. Desværre er det en lidt omstændelig affære at implementere dette interface, og hvis vi ikke har brug for at kunne kontrollere alt, tilbyder .NET to typer, der laver meget af arbejdet for os. I næste indlæg skal vi således se nærmere på DynamicObject og ExpandoObject.

1. Faktisk ”snyder” Microsoft lidt her, for hvis SomeType er en referencetype genererer compileren et kald via callvirt, uanset om der er tale om en virtuel metode eller ej. Fordi vi kalder en metode via et referenceargument, kan referencen være null og derfor udnytter compileren, at callvirt laver et implicit null-tjek- Af den grund ser vi callvirt her i stedet for call.

Dette er andet indlæg i en lille serie om nyhederne i C# 4. I forrige indlæg så vi på udviklingen af C#, og specifikt på motivationen for at udvide sproget med adgang til dynamiske typer. I dette indlæg skal vi se på et konkret eksempel på brug af dynamiske typer.

Så lad os kaste os ud i det. Betragt nedenstående stump kode:

Adder adder = GetAdder();
int result = adder.Add(40, 2);
Console.WriteLine(result);

Det er, som vi kender det. Ingen dynamiske typer. Det er plain vanilla C#, men lad os alligevel bruge et øjeblik på at slå fast, hvad der sker her.

Forudsat at vi har en type kaldet Adder med en metode kaldet Add, der tager to ints og returnerer en int samt en lokal metode ved navn GetAdder, der returnerer en instans af Adder, oversætter dette og fungerer som forventet.

Vi kan udføre det samme på dynamisk vis ved hjælp af Reflection. I så fald ser kode ud som følger:

object adder = GetAdder();
Type adderType = adder.GetType();
object returnObject = adderType.InvokeMember("Add",
   BindingFlags.InvokeMethod, null, adder, new object[] { 40, 2 });
int result = Convert.ToInt32(returnObject);
Console.WriteLine(result);

Ikke alene fylder dette en del mere, det er også sværere at læse, men den grundlæggende funktionalitet er som ovenfor.

Vi har stadig en GetAdder(), men da vi ikke vil lægge os fast på en bestemt type til returværdien, er vi nødt til at betragte den som en instans af object.

Vi vil stadig gerne kalde Add(), men for at kunne gøre det via Reflection, er vi nødt til at have fat i den aktuelle type på returværdien fra GetAdder() først. Via typeobjektet kan vi kalde metoden, men vi er nødt til at beskrive signaturen, hvordan typebinding skal foretages, hvilken instans metoden skal kaldes for samt de relevante argumenter til metoden. Derfor bliver kaldet til InvokeMethod() ret omfattende.

Returværdien er ligeledes repræsenteret via en instans af object, så for at få pillet værdien ud af denne, er vi nødt til at kalde ToInt32(), og herefter er vi i mål.

Ulemperne ved ovenstående er indlysende. Det er tungt at skrive og tungt at læse. Der er adskillige muligheder for fejl på afviklingstidspunktet. Måske har typen ikke en Add(), måske er argumenterne ikke korrekte, måske får vi noget tilbage, der ikke kan konverteres til int.

Dertil kommer, at hver gang vi kalder ovenstående, skal alle disse elementer verificeres, og det tager naturligvis lidt tid.

Hvad er fordelen så? Fordelen er, at ovenstående virker, uanset hvad GetAdder() end returnerer, så længe der er tale om en instans, der har en Add() med den korrekte signatur. Koden er således ikke afhængig af specifikke typer, men derimod specifikke egenskaber ved vilkårlige typer.

Med dynamiske typer får vi større fleksibilitet samt bedre ydelse med en syntaks, der ligger meget tæt op ad den vi kender fra statiske typer. Med dynamiske typer ser koden således ud:

dynamic adder = GetAdder();
dynamic result = adder.Add(40, 2);
Console.WriteLine(result);

Nu ligner koden til forveksling, det vi kender med den ene forskel, at vi har udskiftet de statiske typer med det nye nøgleord dynamic. Ligesom Reflection-eksemplet fungerer dette, uanset hvad GetAdder() end returnerer, så længe den returnerede instans kan honorere kaldet til Add(). Det er fleksibelt og letlæseligt.

Vi har naturligvis stadig samme faldgruber som ved Reflection. Hvis metoden ikke findes, får vi en fejl på kørselstidspunktet. Hvis argumenterne til metoden ikke passer, får vi ligeledes en afviklingsfejl. I teorien kunne vi også få en fejl, hvis WriteLine ikke kunne kaldes med den konkrete instans af result, men eftersom WriteLine() ender med at kalde ToString(), som instansen får fra object, er der ingen ko på isen her.

Den tilgængelige syntaks er ikke den eneste fordel. I vores Reflection-eksempel betaler vi prisen for dynamikken ved hvert kald, så hvis vi kalder ovenstående i en løkke, kommer programmet til at lave det samme arbejde mange gange. Vi kan selvfølgelig gemme resultatet af forarbejdet og genbruge det i løkken, men det kræver mere kode.

Med DLRen får vi dette forærende af selve afviklingsmiljøet i form af call site caching, så når den specifikke Add() metode er blevet identificeret for vores aktuelle instans, gemmes denne oplysning og genbruges automatisk, hvis vi f.eks. kalder Add() flere gange i en løkke.

Okay, er humlen så, at vi blot har fået pænere og hurtigere Reflection? Ikke helt for dynamic kan mere end Reflection, men det ser vi på i næste indlæg.