Hör och läser om "generics" lite här och där... kan någon förklara vad det egentligen betyder på en lite enklare svenska? Känns som nåt nytt i c#-sammanhang?
Generics är nytt i .net från och med .net 2.0 men har funnits i andra språk innan.
Hmm jag är ju ingen klippa på detaljerna men i princip kan man säga att Generic Collections är en samling typoberoende objekt.
Du skapar en klass User tex, med namn, epost och användarid. De består av olika typer dvs string, string, int32.
Med generics kan du sedan använda dig av alla typerna i din klass helt oberoende av vad det är för typ användarid har. En generic lista
Jag tror att du menar rätt men att det kanske blev lite rörigt där?
Vilka typer properties på ett objekt har är inte riktigt relevant i sammanhanget. Det viktiga med listorna är om du behöver typecasta objekten för att kunna komma åt innehållet.
Jämför gärna en otypad lista typ ArrayList:
ArrayList al = new ArrayList();
al.add(1); //går bra
al.add("hepp"); // går bra
al.add(new User()); går också bra,
Men nu måste du typecasta allt som ska ut:
int i = (int)al[0];
User u = (User)al[2];
Hade vi istället använt Generics:
List<User> l = new List<User>();
l.add(1); //går inte bra, bara users tillåts
l.add("hepp"); // går inte bra, bara users tillåts
l.add(new User()); går bra
Hmm, är en arraylist mycket snabbare än en generic list så arraylisten är värd att finnas kvar eller är arraylisten på väg ut tro?
För det finns väl ingen anledning att använda en otypad arraylist om prestanda är ungefär lika som en generic list! Eller? :stud
Nej arraylisten blir på det stora hela mycket mer prestandakrävande!
Men som alltid så måste man ju ha kvar arraylisten för att dels lämna möjligheter för utvecklaren att göra som han vill. Sedan ska det ju vara bakåtkompatibelt osse.
Webservices kan bara hantera arrays av objekt så där kan man inte använda generic collections
Jag är hyfsat säker på att du har fel där. Senast jag skrev en webservice använde jag generic collection. De blir ju bara översatta till ett soap-svar, dvs xml och så länge .net klarar att generera xml från en lista så kommer det att funka.
Gör en sökning på webservice generic collection så får du t.ex kodexempel på msdn där microsoft använer generic collections i webservices.
red:
Ah, jag funderade lite till, du har iof rätt med. För generiska typer kommer säkert bli svårt för soapformattern att serialisera. Det beror med andra ord på vad vi menar med generics i detta sammanhang, En List<string> eller List<MyUserObject> borde ju hur som helst fungera, och efter en del funderande till så lär det bero på att när jag testar så blir den generiska listan automatiskt nedgraderar till en array, heheh :bire
Nu blev mitt inlägg kankse aningen meningslöst men någon kanske slipper undra varför det ändå används generic collections i kodexempel de ser på nätet eller så.
Webservices är ju specat av W3C och där är bara arrays tillåtna. .NET tillåter kanske List ibland men frågan är hur kompatibla dessa webservices blir då man går utanför .NET.
List<> har en metod ToArray() man kan köra men det gäller att det bara finns tillåtna datatyper.
Webservices är ju specat av W3C och där är bara arrays tillåtna. .NET tillåter kanske List ibland men frågan är hur kompatibla dessa webservices blir då man går utanför .NET.
List<> har en metod ToArray() man kan köra men det gäller att det bara finns tillåtna datatyper.
Ja, jag förstår vad du menar, det jag fösökte få fram är just att med både enkla och ganska komplexa datatyper så fungerar det hur som helst (utifrån en programmerares vy i .net), så att generellt säga att generic collections inte fungerar i webservices är i mitt tycke fel eller möjligtvis syftningsfel ;)
Det viktiga att förstå är hur som helst att speccen för webservices inte tillåter generiska typer men att .net:s soapformatter fixar till dem åt oss.
Vad det gäller kompatibilitet utanför .net är jag osäker men jag kan inte se varför det skulle vara skillnad på List och ArrayList, borde till och med vara bättre med List<> eftersom den är starkt typad?
327 ms totalt · 3 externa anrop · v20260731065814-full.f363f448