[C#] Kritiek en praktische adviezen

[mbravenboer]

Ik kwam dit stuk tegen:

http://www.geocities.com/csharpfaq/

Het is een soort C# FAQ met wat links naar aan C# gerelateerde bronnen en tips voor het gebruik van C#. Het is wel aardig om de hot-topics even door te nemen, zodat je met de problemen die daar gesignaleerd worden rekening kunt houden.

De kernpunten van de auteur zijn:

* Prefer interfaces over delegates
* Discourage use of properties
* Do not use user-defined implicit conversions
* Do not use structs
* Do not use boxing and unboxing

Hij noemt dit 'best-practices'. Als je dit zo ziet suggereert hij als best-practice in feite meer om C++ of Java te gaan gebruiken.

Wat vind je van de aangedragen punten?

[whoami]

Pfff, ik vind dat hij een beetje moeilijk doet. Volgens mij is de auteur een Java-programmeur die gewoon iedereen ervan wil overtuigen dat Java beter is dan C# en dat alle features die C# heeft en Java niet toch maar useless en gevaarlijk zijn.

In sommige gevallen is het gewoon gemakkelijker/beter om een delegate te gebruiken ipv interfaces en omgekeerd.

En wat is er mis met properties. Als je een goed OO-model hebt uitgedacht, dan ga je de access-modifiers van uw members niet moeten veranderen. Dat doe je imho enkel en alleen maar als je direct begint te programmeren zonder dat je er eerst een goede class-structuur voor gemaakt hebt.
Properties zijn gewoon gemakkelijk en leesbaar. Java heeft geen properties maar lost dit op door set en get-functies en wat is het wezenlijke verschil?
Als je goede naming-conventions toepast, dan hoef je niet te verwarren tussen properties en member-variables. Ik vind dit nogal ver gezocht.

Waar hij wel een punt heeft, is het verschil in type tussen structs en classes. Hier kan misschien wel wat verwarring ontstaan omdat een struct een value-type is, en een class is een reference-type.

[TheOneLLama]

Ik ben het er wel mee eens dat delegates, event pointers en properties onnodig zijn.. Als je kijkt naar 2 voorbeelden van GUI omgevingen van C++ (Qt) en JAVA (Swing) dan zie je dat het ook zonder deze dingen goed kan (op taal-niveau). Als je dat vergelijkt met Delphi (wel event pointers en properties op language niveau) geef ik voorkeur aan 1 van de anderen..
Deze dingen zijn echter een keuze en onderdeel van de taal.. of je ze gebruikt of niet is nog altijd je eigen beslissing maar iemand dit compleet af te raden vind ik wel ver gaan..

Ook zou je structs alleen maar moeten gebruiken als er hogere performance nodig is (en dus niet al zodra je er hogere perfomance mee kan halen).

Als User-defined implicit conversions is wat ik denk wat het is in C# (ben nog niet erg bekend met C#) dan lijkt het me dat je code daar inderdaad niet veel duidelijker op wordt.

Zoals al blijkt uit m'n posting ben ik niet echt bepaald een expert in C# dus als er wat foutjes zitten in wat ik zeg hier so be it..

[whoami]

Ik vraag me eigenlijk af of implicit conversions eigenlijk toegestaan zijn in C#. C# is toch type-safe, dus verwacht ik dat enkel maar expliciete conversions mogen?

Op zaterdag 01 juni 2002 14:29 schreef TheOneLLama het volgende:
Ik ben het er wel mee eens dat delegates, event pointers en properties onnodig zijn.. Als je kijkt naar 2 voorbeelden van GUI omgevingen van C++ (Qt) en JAVA (Swing) dan zie je dat het ook zonder deze dingen goed kan (op taal-niveau). Als je dat vergelijkt met Delphi (wel event pointers en properties op language niveau) geef ik voorkeur aan 1 van de anderen..

Tja, da's ook een beetje een kwestie van persoonlijke voorkeur. Ik vind het event-model van Delphi en C# (dus met die function-pointers cq delegates) wel prettig werken en veel duidelijker. Maar da's een kwestie van smaak.

[mbravenboer]

whoami: Volgens mij is de auteur een Java-programmeur die gewoon iedereen ervan wil overtuigen dat Java beter is dan C# en dat alle features die C# heeft en Java niet toch maar useless en gevaarlijk zijn.

Mwah, hij vermeldt op z'n website veel C# bronnen en maakt ook een vergelijking tov van C++. Het is wel wat makkelijk om iedereen die kritiek heeft op een constructie in C# gelijk maar af te doen als pro-Java en anti-C#. Je argumentatie van gaat dan snel richting de subjectiviteit van de schrijver, wat een inhoudelijke discussie in de weg staat.

In sommige gevallen is het gewoon gemakkelijker/beter om een delegate te gebruiken ipv interfaces en omgekeerd.

Nou ja, ik mis hier toch wel een argumentatie. We hebben het al in een eerder topic gehad over de relatie tussen interfaces en delegates waarbij iedereen me wat wazig aankeek. Ik denk toch echt dat je beide concepten kunt en moet vergelijken met elkaar.

Het enige voordeel wat ik zie van delegates ten opzichte van interfaces is dat je via delegates functionaliteit kunt gebruiken die de klasse niet heeft aangegeven via een interface. Bij interfaces kan je de functionaliteit van de interface alleen toepassen als de klasse die interface ook daadwerkelijk geimplementeerd heeft. Overigens kan je daarvoor ook wel at-runtime wrappers genereren, maar dat is in ieder geval ranziger dan delegates .

En wat is er mis met properties. Als je een goed OO-model hebt uitgedacht, dan ga je de access-modifiers van uw members niet moeten veranderen. Dat doe je imho enkel en alleen maar als je direct begint te programmeren zonder dat je er eerst een goede class-structuur voor gemaakt hebt.
Properties zijn gewoon gemakkelijk en leesbaar. Java heeft geen properties maar lost dit op door set en get-functies en wat is het wezenlijke verschil?

Het verschil wordt heel goed geillustreerd in het stukje: bij het aanroepen van een property in Java zie je duidelijk dat er een methode wordt aangeroepen. Deze methode kan dure operaties uitvoeren zoals daar ook is geillustreerd. Bij een property in C# laat alleen de naming convention zien of er in werkelijkheid een methode wordt aangeroepen of dat het een directe assignment/get is. Nu is het inderdaad zo dat je die naming convetion ook gewoon goed moet aanhouden, dus in feite moet je dan bekijken of de naming conventie duidelijk is dat een methode aanroep.

Overigens vind ik dit ook een wat minder punt, met de delegates kan ik het meer eens zijn.

[mbravenboer]

whoami: Ik vraag me eigenlijk af of implicit conversions eigenlijk toegestaan zijn in C#. C# is toch type-safe, dus verwacht ik dat enkel maar expliciete conversions mogen?

C# kent wel degelijk implicit conversions, maar die moeten uiteraard wel door de programmeur gedefinieerd zijn in 1 van de betrokken klassen.

Het heeft niet zoveel te maken met type-safety. De impliciete conversies zijn gewoon verborgen methode-aanroepen die een conversie uitvoeren van het 1 type naar het andere. Deze methode moet je zelf implementeren, maar bij het gebruik van de impliciete conversie hoef je deze methode dus niet aan te roepen.

C# gaat uiteraard niet op 1 of andere magische manier een conversie proberen uit te voeren .

Type-safety is trouwens sowieso een term waarmee je uit moet kijken in deze context. C# zal namelijk best garanderen dat er nooit een illegale operatie kan worden uitgevoerd op een item (dat is type-safety), maar kan dit at compile time niet controleren: er kan best een incorrecte cast uitgevoerd worden.

[whoami]

Op zaterdag 01 juni 2002 14:42 schreef mbravenboer het volgende:

Mwah, hij vermeldt op z'n website veel C# bronnen en maakt ook een vergelijking tov van C++. Het is wel wat makkelijk om iedereen die kritiek heeft op een constructie in C# gelijk maar af te doen als pro-Java en anti-C#. Je argumentatie van gaat dan snel richting de subjectiviteit van de schrijver, wat een inhoudelijke discussie in de weg staat.

Ja, idd. Misschien een beetje 'te kort door de bocht' van mij. (Of hoe zeggen jullie Nederlanders dat )

Nou ja, ik mis hier toch wel een argumentatie. We hebben het al in een eerder topic gehad over de relatie tussen interfaces en delegates waarbij iedereen me wat wazig aankeek. Ik denk toch echt dat je beide concepten kunt en moet vergelijken met elkaar.

Het enige voordeel wat ik zie van delegates ten opzichte van interfaces is dat je via delegates functionaliteit kunt gebruiken die de klasse niet heeft aangegeven via een interface. Bij interfaces kan je de functionaliteit van de interface alleen toepassen als de klasse die interface ook daadwerkelijk geimplementeerd heeft. Overigens kan je daarvoor ook wel at-runtime wrappers genereren, maar dat is in ieder geval ranziger dan delegates .

Tja, ik heb hier ooit eens in een topic een post geplaatst met een voorbeeld van een geval waarin ik delegates toepas. Ik zal het topic eens gaan opzoeken.

Edit: hier issie http://gathering.tweakers.net/forum/list_message/13353671#13353671
Ik weet niet hoe je iets dergelijks even makkelijk en leesbaar kunt oplossen dmv interfaces.

Het verschil wordt heel goed geillustreerd in het stukje: bij het aanroepen van een property in Java zie je duidelijk dat er een methode wordt aangeroepen. Deze methode kan dure operaties uitvoeren zoals daar ook is geillustreerd. Bij een property in C# laat alleen de naming convention zien of er in werkelijkheid een methode wordt aangeroepen of dat het een directe assignment/get is. Nu is het inderdaad zo dat je die naming convetion ook gewoon goed moet aanhouden, dus in feite moet je dan bekijken of de naming conventie duidelijk is dat een methode aanroep.

Overigens vind ik dit ook een wat minder punt, met de delegates kan ik het meer eens zijn.

Misschien is het op 't eerste zicht idd niet duidelijk of de property of de member rechtstreeks aangesproken wordt, maar we zijn er het alvast over eens dat door consequente naming-conventions toe te passen dit probleem toch uit de weg kan gegaan worden. Ik vind in sommige gevallen properties gewoon veel duidelijker dan getters en setters.
Bv:

code:

MyObject.Counter++;

tov:

code:

MyObject.SetCounter(MyObject.GetCounter()++);

[Orphix]

Ik heb nog niet zo intensief gewerkt met C#, maar toch even reageren.

Op zaterdag 01 juni 2002 13:25 schreef mbravenboer het volgende:
Ik kwam dit stuk tegen:
* Prefer interfaces over delegates

Ik vind dit toch wel een hele rare gedachtenkronkel die hij hier maakt. In het voorbeeld verwart hij missiles met employees en geeft de taal de schuld

Ik vind delegates niet het mooiste onderdeel van de taal, maar het is op functie niveau wel type-safe. De vrijheid om elke functie toe te wijzen met dezelfde specificaties kan natuurlijk ook in je voordeel werken.

Stel je hebt een heel plausibele delegate voor een 'void DoeIets()'. Je kan dan dit bv koppelen aan het afsluiten van je programma, het aanroepen van een 3rd-party webservice. Plus dat je de binding later gemakkelijk kan veranderen. Zouden al deze onderdelen een bepaalde interface moeten implementeren?
Een interface geeft aan welke set operaties een object kan uitvoeren. Een delegate zie ik meer als de lijm om verschillende componenten met elkaar te laten praten.

* Discourage use of properties

Onzin. Moet ik dan voor elke private member getters/setters gaan schrijven? Dit komt precies op hetzelfde neer.
Zijn 1e voorbeeld gaat niet op omdat een goede C# programmeur standaard al begint met properties. Hierdoor kan je in een later stadium nooit client-code breken.
Het is natuurlijk logisch dat de functie van een property niet mag veranderen.

Het hele efficientie verhaal vind ik een beetje dubieus. Het lijkt me dat de compiler een property zoals deze:

code:

public int Getal
{
get { return getal; }
...

gewoon wegcompileert, en dat je dus direct getal aanspreekt.

* Do not use user-defined implicit conversions

Impliciete conversies komen niet zo vaak voor omdat de gebrukte classes vaak te divers zijn. Het heeft totaal geen betekenis om een class Car naar een class House te casten bijvoorbeeld.
Bij het casten van class<->class is het zeker mooier om dit via een constructor te doen.

Een veel sterker argument (wat hier niet genoemd wordt) om geen impliciete conversies te gebruiken is dat de compiler via allerlei wegen zal proberen uit te vinden die cast mogelijk te maken. Stel je hebt een impliciete int cast. Deze code:
float a = MijnClass;
Zal dan misschien niet opleveren wat je verwacht omdat bij de conversie naar int het getal wordt afgerond.

* Do not use structs

Structs moet je gewoon benaderen als primitieven. Microsoft gebruikt voor structs voor vrij primitieve objecten (Points, Size, etc). Dit gaat helemaal niet in tegen het 'principle of uniformity' omdat programmeurs die objecten instinctief gaat behandelen als value-types.
Stel je voor dat je een paint functie hebt waarbij de locatie wordt aangegeven van je control. Ik denk dat 9 van de 10 programmeurs niet
Point p = new Point(pointFromCaller)
zal gebruiken aan het begin van hun functie wanneer ze de locatie gaan veranderen.

* Do not use boxing and unboxing

Dat zal een beetje moeilijk gaan Moet je zeker voor elke primitieve een wrapper gaan bouwen
Nou de argumenten hier overlappen een beetje met die van het structs probleem. Boxing/unboxing is bedoelt om primitieves te kunnen behandelen als een object. Op deze manier kan je dus zowel integers als objecten in een ArrayList proppen.

Hij gebruikt in het voorbeeld de 'is' operator, waarom niet de equality == operator ? Die doet namelijk precies wat hij wil, de waardes vergelijken.

References vergelijken bij primitieven is vrij onzinnig omdat die meestal niet gelijk zijn en de waardes zelf vergelijken gaat ook nog eens snel.

_{dit is lang he}

[mbravenboer]

whoami: Of hoe zeggen jullie Nederlanders dat

Je mag het ook wel op z'n Belgisch zeggen hoor, kunnen wij ook eens lachen .

Tja, ik heb hier ooit eens in een topic een post geplaatst met een voorbeeld van een geval waarin ik delegates toepas. Ik zal het topic eens gaan opzoeken.

Ok. Ik heb zelf overigens in C# ook wel delegates gebruikt omdat je er sowieso niet omheen kan als je met de .NET libraries werkt, maar in m'n eigen werk geef ik toch vaak de voorkeur aan interface die duidelijke de capaciteit van een klasse aangeven.

Bv:

code:

MyObject.Counter++;

tov:

code:

MyObject.SetCounter(MyObject.GetCounter()++);

Wat dacht je van:

MyObject.IncreaseCounter();

.

Overigens is het inderdaad wel zo dat je in get-set situaties (zoals hier het geval is) duidelijk voordeel hebt van properties qua compactheid als je 1 van de compacte assignments kunt gebruiken.

[mbravenboer]

Orphix: Ik vind dit toch wel een hele rare gedachtenkronkel die hij hier maakt. In het voorbeeld verwart hij missiles met employees en geeft de taal de schuld

Het gaat in zijn verhaal om het aangeven van capaciteiten. Als je van interfaces gebruik maakt geeft een klasse aan dat hij bepaalde funcionaliteit bezit.

Met delegates is dit niet mogelijk om dat slechts het signatuur van de methode gelijk moet zijn aan de delegate declaratie. Er is dan echter geen enkele garantie dat die methode ook daadwerkelijk semantisch gezien doet waar de delegate voor gedefinieerd is.

Bij interface heeft de schrijver van de klasse hier controle over: hij geeft de capaciteit aan.

Een interface geeft aan welke set operaties een object kan uitvoeren. Een delegate zie ik meer als de lijm om verschillende componenten met elkaar te laten praten.

Mwah, set operaties vind ik wel wat beperkt voor interfaces. ook interface kan je gebruiken om componenten met elkaar te laten babbelen. Denk maar eens aan de Runnable, Comparator, Comparable, SAX ContentHandler, ErrorHandler enzovoorts.

Onzin. Moet ik dan voor elke private member getters/setters gaan schrijven? Dit komt precies op hetzelfde neer.

Nee: als je getters en setters gebruikt moet je de getters en setters ook echt aanroepen. Je ziet dus wat er gebeurt door middel van de methode aanroep. Bij properties zie je wat er gebeurt door de naming convention.

gewoon wegcompileert, en dat je dus direct getal aanspreekt.

Het gaat niet om simpele gets en sets (die worden inderdaad ge-inlined, net als simpele gets en sets in Java).

Het gaat in zijn performance inzicht argument over extra operaties die worden uitgevoerd door een getter of setter. Een get of set hoeft namelijk niet slechts een waarde op te leveren of te setten, maar kan juist ook veel meer doen.

Ik zeg trouwens niet dat ik het overal mee eens ben, wel vind ik dat je goed rekening moet houden met de punten die genoemd worden. Je moet dus aardig wat afweten van de betekenis van de diverse concepten voordat je er op een veilige en vertrouwde manier mee om kunt gaan.

[whoami]

Op zaterdag 01 juni 2002 15:00 schreef mbravenboer het volgende:

Je mag het ook wel op z'n Belgisch zeggen hoor, kunnen wij ook eens lachen .

Ik zei het op z'n Nederlands omdat ik niet zo direct een equivalente Belgische uitspraak weet...

Ok. Ik heb zelf overigens in C# ook wel delegates gebruikt omdat je er sowieso niet omheen kan als je met de .NET libraries werkt, maar in m'n eigen werk geef ik toch vaak de voorkeur aan interface die duidelijke de capaciteit van een klasse aangeven.

Heb het ondertussen gevonden.

Wat dacht je van:

code:

MyObject.IncreaseCounter();

.

Ja, idd. Maar ik wou gewoon maar een punt duidelijk maken. Stom voorbeeld van me misschien.

[Verwijderd]

Ik moet zeggen dat ik vooral dat punt over die properties gewoon vette onzin vind. Punt.

Hij vergelijkt

public void Calc(int[] foo)
{
Sum = 0;
for (int i = 0; i < foo.Length; i++)
Sum += foo[i];
}
////////////////////////////////////
{
Sum = 0;
for (int i = 0; i < foo.Length; i++)
SetSum(GetSum() + foo[i]);
}
////////////////////////////////////
{
int temp = 0;
for (int i = 0; i < foo.Length; i++)
temp += foo[i];
SetSum(temp);
}

Maar ervan uitgaande dat Sum gedefinieerd is als:

code:

public int Sum
{
 get
 {
  return _sum;
 }
 set
 {
  _sum = value;
 }
}

Dan zie ik toch echt niet wat er zo ineffecient aan is. In het voorbeeld dat de auteur aandraagt wordt immers ook steeds een variabele opgevraagd en geset.
Bovendien maakt hij de code wel logisch bij de Get/Set manier en niet bij de properties manier...

Ik vind Properties juist een van de allergrootste voordelen van C# t.o.v. Java .

/me vindt z'n eigen coding guidelines veel mooier, beter en duidelijker

[Verwijderd]

omg mbravenboer on the loose Welcome back..

[Orphix]

Op zaterdag 01 juni 2002 15:11 schreef mbravenboer het volgende:
Het gaat in zijn verhaal om het aangeven van capaciteiten. Als je van interfaces gebruik maakt geeft een klasse aan dat hij bepaalde funcionaliteit bezit.

Met delegates is dit niet mogelijk om dat slechts het signatuur van de methode gelijk moet zijn aan de delegate declaratie. Er is dan echter geen enkele garantie dat die methode ook daadwerkelijk semantisch gezien doet waar de delegate voor gedefinieerd is.

Ik heb toch liever het blackbox-idee. De klasse roept de delegate aan wanneer dat nodig is en wat de client-programmeur ermee doet is zijn taak. Als hij dan missiles wil sturen, so be it.
Aan een delegate kun je ook meerdere functies hangen, hoe wil je dit oplossen met interfaces?

Nee: als je getters en setters gebruikt moet je de getters en setters ook echt aanroepen. Je ziet dus wat er gebeurt door middel van de methode aanroep. Bij properties zie je wat er gebeurt door de naming convention.
...

Ik heb alleen nog maar in vs.net gewerkt en dan zie je tijdens het typen al duidelijk wat een property is en wat niet, ook in de documentatie staat dit.

Maar ook al weet je het niet of het een property is of niet, wat maakt het uit?
Ik ben het met je eens dat kostbare operaties een aparte methode moeten krijgen. Maar stel dat een property zoveel doet dat het traag wordt. Dan kan je alsnog besluiten om eenmaal die property op te halen en daar verder mee te werken.

[TheOneLLama]

Op zaterdag 01 juni 2002 14:37 schreef whoami het volgende:
Tja, da's ook een beetje een kwestie van persoonlijke voorkeur. Ik vind het event-model van Delphi en C# (dus met die function-pointers cq delegates) wel prettig werken en veel duidelijker. Maar da's een kwestie van smaak.

Precies.. en in C# en zeker in Delphi wordt je toch vooral richting in gedreven.. Maar om nou te negeren dat het in die talen werkt en te zeggen: dat moet je dus niet gebruiken is een stapje te ver

Op zaterdag 01 juni 2002 14:52 schreef mbravenboer het volgende:

[..]

C# kent wel degelijk implicit conversions, maar die moeten uiteraard wel door de programmeur gedefinieerd zijn in 1 van de betrokken klassen.

Het heeft niet zoveel te maken met type-safety. De impliciete conversies zijn gewoon verborgen methode-aanroepen die een conversie uitvoeren van het 1 type naar het andere. Deze methode moet je zelf implementeren, maar bij het gebruik van de impliciete conversie hoef je deze methode dus niet aan te roepen.

Dan lijkt mij gewoon zelf een method maken en die aanroepen mij duidelijker.. (desnoods op basis van een interface).

[mbravenboer]

Gordijnstok: omg mbravenboer on the loose Welcome back..

Mwah, ik ervaar deze reacties niet als verliezen hoor . Allereerst heb ik het stuk niet geschreven, alhoewel ik het wel met veel zaken min of meer eens bent. Probleem is alleen dat je ze van alle kanten moet belichten als je gaat beoordelen of ze zinvol zijn. Dat gebeurt hier niet bepaald want je kan van elke taal-constructie wel een beperking of probleem signaleren.

Wat ik wel jammer vind is dat er allerlei suiker en minder relevant materiaal aan C# is toegevoegd ten opzichte van Java, terwijl er veel meer echt innovatieve ideeen in opgenomen hadden kunnen worden zoals bijvoorbeeld in Nice. Met name het aangeven dat een variabele null kan zijn of dat een methode null kan opleveren vind ik erg fraai en lost een echt probleem op wat er is in de taal Java.

[mbravenboer]

Orphix: Ik heb toch liever het blackbox-idee. De klasse roept de delegate aan wanneer dat nodig is en wat de client-programmeur ermee doet is zijn taak. Als hij dan missiles wil sturen, so be it.

Het punt is juist dat hij ze daar niet wilde sturen .

Aan een delegate kun je ook meerdere functies hangen, hoe wil je dit oplossen met interfaces?

Als je dat nodig hebt kan je een implementatie van de interface maken die twee andere implementaties van de interface combineert. Voordeel daarvan is dat je ook nog extra gedrag kunt toevoegen.

Voorbeeld:

code:

public interface Filter<T> {
  public boolean accept(T item);    
}

public class OrFilter<T> implements Filter<T> {

  private Filter<T> _first;
  private Filter<T> _second;

  public OrFilter(Filter<T> first, Filter<T> second) {
    super();
    _first = first;
    _second = second;
  }

  public boolean accept(T item) {
    return _first.accept(item) || _second.accept(item);
  }
}

Als jij een Runnable wilt die meerdere Runnables kan runnen, implementeer je een Runnable die dat doet .

Helaas is dat vanwege de verbositeit van deze categorie talen vrij veel werk: het is juist erg gebruikelijk om op deze manier te werken in compactere, declaratieve talen.

[Scare360]

Wat een kwats...

by the way Delegates zijn niets meer dan "the good old" functie pointers alleen dan op zijn type safes

Het verhaal dat je juist geen properties moet gebruiken zegt voor mij al genoeg Als je het dan toch niet wil zien... Een grote brok abstractie op je implementatie. Als je dan toch nog op optimalisatie wil neuken dan moet je uberhaupt al niet voor C# kiezen, maar gezellig gaan zitten rommelen in C++ of assembly (function calls, de lolbroek).

Dat verhaal over structs is helmaal om te brullen. Voor mensen die dan echt willen weten hoe het zit. Mensen die echt van een ervaren programmeur willen horen wat nou net de tradeoffs zijnvan C# tov Java/C++. Mensen die een snelle efficiente insight willen hebben:

Lees, "C# Unleashed by Joseph Mayo"

Alle info op mtb die FAQ is wel zo extreem kort door de bocht. Duik de MSDN eens een keer in, MS geeft deze keer heel duidelijk aan waarom dingen wel of niet volgens een bepaalde methodiek aan te pakken. MS geeft ook duidelijk aan dat de taal niet heilig makend is, maar het Framework en de gedachtengang achter .NET voor de programmeurt.

mtb het delegate/event model vs the good old IObservable/IObserver artikel...erg leerzaam! Daarin wordt duidelijk uiteengezet waarom geen Interfaces en wel

MS observerpattern

[whoami]

Op zaterdag 01 juni 2002 15:56 schreef mbravenboer het volgende:


Mwah, ik ervaar deze reacties niet als verliezen hoor .

Off-Topic.

Ik denk niet dat er bedoeld werd dat je aan het verliezen waart.

To be on the loose:aan de rol, aan de zwabber zijn.

[MSalters]

't Is wel een stuk van iemand die onbekend is met C++ :

Q: What do delegates buy you?
A: Delegates enable scenarios that some other languages have addressed with function pointers. However, unlike function pointers, delegates are object-oriented and type-safe.

Q: Are delegates really type-safe?
Not really. A delegate instance does not know or care about the classes of the methods it encapsulates; all that matters is that those methods be compatible with the delegate's type.

Ter vergelijking, in C++ zijn function pointers wel really typesafe, en desgewenst ook OO (pointer to member).

tweede voorbeeld van site:

... in C++ the syntax for using a class/struct reference is very different from the syntax for using a class/struct value.

Let op het verschil tussen a.x en b.x

code:

#include "myClass.h"
myClass  a;
myClass& b = a;
a.x=1;
b.x=2;

Wereld van verschil, toch ?