Type inference of interferentie?

Met de komst van Visual Studio 2008 en C# 3.0 zijn we weer met een hele golf
aan taalvernieuwingen overspoeld. Waar generics het meest opvallende was bij C# 2.0, is nu toch wel LinQ het nieuwe stokpaardje. Hierbij moet wel vermeld worden dat LinQ niet mogelijk zou zijn zonder de hulp van de mindere goden zoals Lambda expressies, Extension Methods, Anonymous Types en Type Inference.

De laatste uit het rijtje is eigenlijk de simpelste vernieuwing, het makkelijkste te gebruiken maar het meest omstreden.

Hoewel aan Type Inference zelfs een Wikipedia pagina is gewijd, is het concept erg eenvoudig.

C# is als taal Type Safe. Dit betekent dat iedere instantie van een klas
van een bepaald type is en gedurende zijn hele levensduur dat ene type zal
uitbeelden met al zijn beperkingen. Dit uit zich in b.v.

Button mijnButton = new Button();

Ok, en waar blijft dan Type Inference? Nou, met C# 3.0 kunnen we ook
schrijven:

var mijnButton = new Button();

Het keyword var beschrijft toch dat de variabele een Button is want de
compiler kan dat afleiden uit de assignment. Laat het duidelijk zijn: Het is
geen Variant, geen Late binding en ook geen soort van base class waar alles naar
gecast kan worden. Na deze instanciering zal mijnButton alleen het gedrag van
een Button kunnen tonen, het blijft een Type Safe declaratie.

Type Inference is kort door de bocht een verkorte notatie. Prettige
bijkomstigheid is dat pas tijdens het moment van compileren het type echt wordt
vastgesteld. Mocht ik als ontwikkelaar van menig veranderen dan hoef ik alleen
maar de assignment aan te passen.

Waarom is dit in de taal opgenomen? Microsoft had deze notatie nodig voor
LinQ, en speciaal door het introduceren van Anonymous Types. Met C# 3.0 kunnen namelijk ‘on the fly’ nieuwe type safe types gedefinieerd worden. Dus wordt het lastig voor de ontwikkelaar om vooraf alle mogelijke types te declareren terwijl de compiler al lang weet wat het type zal uitbeelden.

Nu blijken er inmiddels drie kampen te zijn ontstaan over zoiets simpels als var.

Ook binnen ons ontwikkelteam is inmiddels de discussie over de reikwijdte van
het gebruik van Type Inference gevoerd.

Zelf ben ik voorstander om het zo veel mogelijk te gebruiken. Het is een nieuwe taaleigenschap die gemakkelijk toegepast kan gaan worden en het leven van een ontwikkelaar weer een stukje makkelijker maakt (minder typen, minder code, sneller refactoren). Ook kan je er niet eens aan ontsnappen zodra de eerste LinQ code ingetyped gaat worden.

Ik weet het, in .Net 1.0 hadden we het ook niet nodig en die
code compileert ook nog steeds prima. En ja, je bent overgeleverd aan de
compiler en editor om te achterhalen welke klasse achter een var schuil gaat.
Maar dat vind ik niet voldoende om Type Inference in de ban te doen, ik heb de
tooling altijd tot mijn beschikking.

Het is ook steeds weer wennen aan de nieuwe taaleigenschappen. Iedere drie jaar is er een kleine revolutie met de introductie van een nieuwe compiler. We zitten dan weer in de, zeg maar, ontkennende fase. Maar na de berusting blijkt dat het helemaal niet nodig om exact te weten welke types aangemaakt of geïnstancieerd wordt. Het is de kunst van het loslaten, de compiler kan het type prima controleren en ik hoef mij alleen maar te concentreren op het gedrag wat de variabele om dat moment moet tonen. Wel moeten variabelenamen nog beschrijvender gekozen worden.

Helaas bleken al onze argumenten voor het toepassen van Type Inference niet voldoende. Het voornaamste tegenargument was dat de code minder leesbaar was buiten Visual Studio…

Hmm, wie gaat code tegenwoordig bekijken met een andere viewer dan Visual Studio? Nou ehh, collega’s die met TeamSystem werken.

En dat is vreemd, Team System is een prachtige aanvulling op Visual Studio en dat wordt als argument naar voren gebracht.

Wat blijkt? Bij het uitvoeren van peer code review worden regelmatig aanpassingen in de code vergeleken met vorige versies en daar heeft Microsoft enkel aardige (difference) viewers voor beschikbaar. Sterker nog, zowel binnen Visual Studio als met de Web Access client van Team System is broncode op eenzelfde manier te vergelijken. Er daarbij is er geen beschikking over Intellisense, zodat het gekozen type niet te zien is, zoals in Visual Studio.

Dit doet mij voorkomen als dat de test (de peer review) het resultaat (de ingetypte code) beïnvloedt, een principe uit de kwantummechanica en gepubliceerd door Werner Heisenberg in 1927.

Peer reviews zijn onmisbaar en broncode moet correct en eenduidig gedrag vertonen. Broncode moet ook transparant en testbaar zijn. Maar het is vreemd dat de manier waarop broncode reviews worden uitgevoerd, invloed heeft op het intypen van diezelfde broncode. Waar bij Star Trek al lang een oplossing is uitgevonden voor deze dualiteit in hun transporters wordt de moderne C# ontwikkelaar teruggeworpen naar 2003.

Kan iemand vertellen of in Visual Studio 2010 eindelijk intellisense in het scherm voor het vergelijken van broncode is gebouwd? Dan hoef ik nog maar twee jaartjes te wachten… Beam me up, ScottGu!

Advertenties