mboost-dp1
Hvilken .NET Framework version og hvorfor?
#50: Silverlight og Javascript kan interagere med hinanden og du kan kalde metoder på kryds og tværs og det var et lige så stort mareridt som COM interaction før dynamic supporten i C#, hvor det nu er uhyggelig simpelt.
#51: præcis, hviket er en af hoved-årsagerne til at vi nu har fået dynamic support i C#.
#51: præcis, hviket er en af hoved-årsagerne til at vi nu har fået dynamic support i C#.
#52
Så nu har vi fået dynamics for at bruge JavaScript... før var det for at bruge Silverlight, eller hvad? :p
Igen, COM forbedringerne i .NET 4.0 var primært optional-parameters i C# 4.0.
Silverlight er *seperat* fra .NET. SL4 har dynamics, SL3 har ikke.
På WP7 kører vi SL3, på C# 4.0 (uden dynamics)
Så nu har vi fået dynamics for at bruge JavaScript... før var det for at bruge Silverlight, eller hvad? :p
Igen, COM forbedringerne i .NET 4.0 var primært optional-parameters i C# 4.0.
Silverlight er *seperat* fra .NET. SL4 har dynamics, SL3 har ikke.
På WP7 kører vi SL3, på C# 4.0 (uden dynamics)
#53: Det er korrekt at silverlight også anvendes i andre sammenhænge idag, som f.eks. på WP7, men hovedområdet for Silverlight har hidtil været afvikling i en browser og her havde man det problem at et typestærkt sprog gjorde det besværligt at interagere med javascript i browseren, fordi man skulle ud i nogle frygtelige invoke-kald.
Eftersom Microsoft ønskede at pushe Silverlight og samtidig også anerkendte at der blev foretaget rigtig meget COM-udvikling i C#, så valgte de at indføre dynamic support og optional parameters.
Af de 2 er optional parameters dog bare lidt syntaktisk sukker, hvor dynamic radikalt simplificerer den nødvendige kode.
Eftersom Microsoft ønskede at pushe Silverlight og samtidig også anerkendte at der blev foretaget rigtig meget COM-udvikling i C#, så valgte de at indføre dynamic support og optional parameters.
Af de 2 er optional parameters dog bare lidt syntaktisk sukker, hvor dynamic radikalt simplificerer den nødvendige kode.
#53
Silverlight har *intet* at gøre med JavaScript interaktion. Hvor har du fået den ide fra? Det er AJAX.NET du snakker om.
Silverlight er XAML, som renderes som et custom plugin, ligesom Flash, og det eneste man bruger er et HTML tag der bootstrapper silverlight applikationen i html dokumentet.
INTET JAVASCRIPT, INTET!
Derudover blev Silverlight udviklet flere år før dynamics og DLR, og optional-parameters har som sagt, været i .NET siden dag 1, men ikke i C# (sproget) før C# 4.0
Silverlight har *intet* at gøre med JavaScript interaktion. Hvor har du fået den ide fra? Det er AJAX.NET du snakker om.
Silverlight er XAML, som renderes som et custom plugin, ligesom Flash, og det eneste man bruger er et HTML tag der bootstrapper silverlight applikationen i html dokumentet.
INTET JAVASCRIPT, INTET!
Derudover blev Silverlight udviklet flere år før dynamics og DLR, og optional-parameters har som sagt, været i .NET siden dag 1, men ikke i C# (sproget) før C# 4.0
hvor dynamic radikalt simplificerer den nødvendige kode.Dynamics i C# er også implementeret som sukker. Det er typisk typed, ikke loose-typed!
#57: Jeg har kodet Silverlight professionelt i 2 år, så jeg skulle mene jeg har et vist grundlag for at udtale mig.
Nu googlede jeg lige lidt for dig og her er f.eks. hvad Anders Hejlsberg selv har udtalt i forb. med dynamic supporten i C#:
http://www.version2.dk/artikel/8896-c-4-bliver-dyn...
Nu googlede jeg lige lidt for dig og her er f.eks. hvad Anders Hejlsberg selv har udtalt i forb. med dynamic supporten i C#:
»Er det kætteri?« spørger Anders Hejlsberg retorisk til publikum i den tætpakkede sal. Han forklarer, at han stadig er en stor fan af statiske sprog. Men C# er ikke en ø, men må være i stand til at tale med andre dynamiske sprog. Det er især bindingen til Javascript i Silverlight, som er vigtig. Andre eksempler er dom-objekter i XML og HTML, som kan glide mere gnidningsfrit ind i C#.
http://www.version2.dk/artikel/8896-c-4-bliver-dyn...
#58
I så fald undre det mig at du blander tingene så meget sammen. At du kan sende kald til SL (ligesom til Flash) fra JS, ændre ikke på at Silverlight ikke direkte har noget med JavaScript at gøre.
Og det har ihvertfald intet med DLR at gøre.
Ligeledes er din information omkring COM fuldstændig forvildet.
I så fald undre det mig at du blander tingene så meget sammen. At du kan sende kald til SL (ligesom til Flash) fra JS, ændre ikke på at Silverlight ikke direkte har noget med JavaScript at gøre.
Og det har ihvertfald intet med DLR at gøre.
Ligeledes er din information omkring COM fuldstændig forvildet.
#59: Jeg har hele tiden argumenteret for at Silverlight integrationen med Javascript var et af hovedargumenterne for dynamics i C#, hvilket også er det Anders Hejlsberg selv siger, jeg ved ikke hvor du har det andet fra og dynamics er jo netop opkobling imod DLR'en, så det har i høj grad noget med den at gøre.
Og DLR'en giver også en masse fordele i forhold til COM, jeg kan ikke se hvorledes det er "forvildet".
Og DLR'en giver også en masse fordele i forhold til COM, jeg kan ikke se hvorledes det er "forvildet".
Source plx.mstify (60) skrev:hvilket også er det Anders Hejlsberg selv siger
Fordi dynamics er C# specifikt. Og Silverlight er *IKKE* sprog-specifikt. Altså, det er tvivlsomt at de har noget som helst med hinanden at gøre.
Hvilke? Mig bekendt er der ingen...mstify (60) skrev:Og DLR'en giver også en masse fordele i forhold til COM, jeg kan ikke se hvorledes det er "forvildet".
#62
Det er ikke et citat, det er journalistens egne sammenbinding af emnerne. Jeg har faktisk set hele den session fra PDC, og tydeligvis har journalisten hos version2 ikke været særlig vågen.
Så hvis det er din eneste kilde til den information, så har du altså misforstået alting, totalt.
Han bruger optional parameters, og ikke dynamics, i den session, til at give bedre COM integration.
Og han bruger ikke dynamics i forbindelse med Silverlight, overhovedet.
JavaScript delen omhandler DLR, som senere blev sat i forbindelse med IronPython/Ruby. *ikke* Silverlight.
Det er ikke et citat, det er journalistens egne sammenbinding af emnerne. Jeg har faktisk set hele den session fra PDC, og tydeligvis har journalisten hos version2 ikke været særlig vågen.
Så hvis det er din eneste kilde til den information, så har du altså misforstået alting, totalt.
Han bruger optional parameters, og ikke dynamics, i den session, til at give bedre COM integration.
Og han bruger ikke dynamics i forbindelse med Silverlight, overhovedet.
JavaScript delen omhandler DLR, som senere blev sat i forbindelse med IronPython/Ruby. *ikke* Silverlight.
Og sammenhængen mellem dynamics og COM, er som Brian så fint skriver i kommentarene, at du kan have COM integration med dynamiske sprog -- ved at bruge statiske typer i RESTEN af programmet!
*ikke* ved at bruge dynamics til selv COM delen -- det kan nemlig ikke lade sig gøre.
*ikke* ved at bruge dynamics til selv COM delen -- det kan nemlig ikke lade sig gøre.
Altså INDEN at Silverlight fik en CLR i version 2 så JavaScript den eneste måde man kunne kode på i Silverlight:
http://en.wikipedia.org/wiki/Silverlight#Silverlig...
Jeg kan huske at jeg syntes det var en kæmpe turnoff dengang. Men Silverlight og JavaScript har unægteligt hængt sammen.
http://en.wikipedia.org/wiki/Silverlight#Silverlig...
Jeg kan huske at jeg syntes det var en kæmpe turnoff dengang. Men Silverlight og JavaScript har unægteligt hængt sammen.
Måske, men det har bare ikke særlig meget at gøre med Silverlight i dag, og slet ikke det subset af Silverlight der bruges på WP7.Trentors (66) skrev:Jeg kan huske at jeg syntes det var en kæmpe turnoff dengang. Men Silverlight og JavaScript har unægteligt hængt sammen.
Så at argumentere for at det har nogetsomhelst at gøre med dynamics, ud fra en fejlskreven artikel på version2, er virkelig ikke noget jeg vil tage seriøst.
Ja, selvfølgelig kan du sende kald fra JS til SL, fordi det nu engang kan være smart mht. bannere, eller lign. Men overordnet har det intet at gøre med Silverlight, eller DLR for den sags skyld.
Jeg vil sågar tvivle på om Silverlight overhovedet har DLR adgang i SL4.
#68: Jeg har aldrig postuleret at javascript giver nogen som helst mening i forbindelse med Silverlight til WP7, det er dig der insisterer på den vinkel.
Jeg ved at Anders Hejlsberg har udtalt det flere gange og artiklen var blot den første den bedste jeg faldt over da jeg lige lavede en hurtig google-søgning efter en udtalelse, at du mener den er grundlaget for min argumentation kan jeg ikke tage seriøst og at du oveni mener at journalisten har opdigtet det hele er endnu sværere at tage seriøst.
At du insisterer på at Silverlight, Javascript og DLR ikke har noget med hinanden at gøre er ganske enkelt ikke korrekt, men sålænge du åbenbart kun interesserer dig for Silverlight til WP7 er det sikkert også ligemeget om du forstår det eller ej.
Jeg ved at Anders Hejlsberg har udtalt det flere gange og artiklen var blot den første den bedste jeg faldt over da jeg lige lavede en hurtig google-søgning efter en udtalelse, at du mener den er grundlaget for min argumentation kan jeg ikke tage seriøst og at du oveni mener at journalisten har opdigtet det hele er endnu sværere at tage seriøst.
At du insisterer på at Silverlight, Javascript og DLR ikke har noget med hinanden at gøre er ganske enkelt ikke korrekt, men sålænge du åbenbart kun interesserer dig for Silverlight til WP7 er det sikkert også ligemeget om du forstår det eller ej.
#69
Nej, jeg påpeger at SL på WP7 *også* er en vinkel for Silverlight -- som absolut intet har med JavaScript at gøre, hvilket igen underbygger at Silverlight generelt ikke har en skid med JavaScript at gøre.
Journalisten er tydeligvis ikke programmør, så hvorfor forvente han forstår noget som helst af det alligevel.
Nej, jeg påpeger at SL på WP7 *også* er en vinkel for Silverlight -- som absolut intet har med JavaScript at gøre, hvilket igen underbygger at Silverlight generelt ikke har en skid med JavaScript at gøre.
Men du har ingen kilder på det? Fordi han siger overhovedet ikke nogetsomhelst i den retning på PDC2008.mstify (69) skrev:Jeg ved at Anders Hejlsberg har udtalt det flere gange
Jeg har faktisk set hans session på PDC2008. Så det er klart jeg ikke tager journalisten seriøs.mstify (69) skrev:og at du oveni mener at journalisten har opdigtet det hele er endnu sværere at tage seriøst.
Journalisten er tydeligvis ikke programmør, så hvorfor forvente han forstår noget som helst af det alligevel.
Du har endnu ikke kommet med en forklaring eller nogen som helst former for referencer der underbygger at det har noget med hinanden at gøre.mstify (69) skrev:At du insisterer på at Silverlight, Javascript og DLR ikke har noget med hinanden at gøre er ganske enkelt ikke korrekt
Og lige for at dementere dine udsagn omkring SL yderelige (jeg går ud fra du har fattet at du tog fejl mht. COM nu).
http://blogs.msdn.com/b/hugunin/archive/2007/04/30...
Igen, DLR er udviklet til .NET, så alt hvad der nu engang kører .NET, kan gøre brug af DLR'en. Intet om at DLR'en var udviklet *til* Silverlight.
Specielt ikke når det første sprog på DLR'en var python (IronPython), og ikke JavaScript. (IronPython var også den platform der blev mest udvklet, og først blev udgivet som Open Source).
Med SL 2.0 kom der så CLR support, udover DLR supporten, og når folk så kunne bruge C#, var der sku ingen der gad kode i IronPython, og projektet er sidenhen dødt.
For slet ikke at nævne at IronJScript blev droppet i 2009.
Altså, Silverlight har intet at gøre med JavaScript, EOD.
Og så vil jeg slutte af med at anbefale dig at se hvad Anders faktisk sagde til PDC2008.
Det kunne jo være du kunne lære noget :o
http://blogs.msdn.com/b/hugunin/archive/2007/04/30...
Coupled with the Silverlight 1.1 platform announced today, it even lets languages share a sandboxed security model and browser integration. This means that developers building browser-based applications can now use their preferred language even for client-side code.
Igen, DLR er udviklet til .NET, så alt hvad der nu engang kører .NET, kan gøre brug af DLR'en. Intet om at DLR'en var udviklet *til* Silverlight.
Specielt ikke når det første sprog på DLR'en var python (IronPython), og ikke JavaScript. (IronPython var også den platform der blev mest udvklet, og først blev udgivet som Open Source).
Med SL 2.0 kom der så CLR support, udover DLR supporten, og når folk så kunne bruge C#, var der sku ingen der gad kode i IronPython, og projektet er sidenhen dødt.
For slet ikke at nævne at IronJScript blev droppet i 2009.
Altså, Silverlight har intet at gøre med JavaScript, EOD.
Og så vil jeg slutte af med at anbefale dig at se hvad Anders faktisk sagde til PDC2008.
Det kunne jo være du kunne lære noget :o
#71: omg! Jeg tager ikke fejl hverken mht. COM eller Silverlight og du bliver ved med at tolke mine udtalelser og lægge ord i munden på mig jeg aldrig har sagt.
Jeg har aldrig postuleret at DLR'en er indført pga. Silverlight, jeg har postuleret at Silverlight og COM er nogle af hovedargumenterne for at C# er blevet koblet op på DLR'en. Der er en betydelig forskel.
Jeg tror ikke det er mig der behøver at lære noget her, du er jo fuldstændig ignorant når du stædigt fastholder at silverlight og javascript-interaktion ikke giver mening - det tyder kraftigt på at du aldrig har udviklet silverlight til andet end WP7. Hvis det ikke giver mening, så har jeg godt nok skrevet meget meningsløs kode - det må jo være et mirakel at det virker så.
Og nej jeg har ikke tænkt mig at sidde og glo den der video igennem for at se hvad han siger eller ikke siger, det er fuldstændig ligegyldigt - det var blot et eksempel, du griber efter halmstrå.
Jeg har aldrig postuleret at DLR'en er indført pga. Silverlight, jeg har postuleret at Silverlight og COM er nogle af hovedargumenterne for at C# er blevet koblet op på DLR'en. Der er en betydelig forskel.
Jeg tror ikke det er mig der behøver at lære noget her, du er jo fuldstændig ignorant når du stædigt fastholder at silverlight og javascript-interaktion ikke giver mening - det tyder kraftigt på at du aldrig har udviklet silverlight til andet end WP7. Hvis det ikke giver mening, så har jeg godt nok skrevet meget meningsløs kode - det må jo være et mirakel at det virker så.
Og nej jeg har ikke tænkt mig at sidde og glo den der video igennem for at se hvad han siger eller ikke siger, det er fuldstændig ligegyldigt - det var blot et eksempel, du griber efter halmstrå.
Det må det jo have gjort, da den JavaScript interaktion der var i forbindelse med DLR'en blev udfaset for 2 år siden.mstify (72) skrev:Hvis det ikke giver mening, så har jeg godt nok skrevet meget meningsløs kode - det må jo være et mirakel at det virker så.
Medmindre du altså kun har kodet i Silverlight 1.1, hvor jeg i så fald, ikke vil tage in erfaring i betragtning i dag.
Men du kan jo prøve at underbygge dine argumenter. Jeg synes at have dementeret dine godt og grundigt nu.
(Og måske skulle du prøve at kode COM integration selv -- det kan man forresten ikke i Silverlight, da det kræver medium trust, hur hur)
#73: Det er jo 2 helt forskellige ting .... I gamle dage kodede man javascript op imod Silverlight, det gør man ganske rigtigt ikke idag, der anvender man typisk C#.
Men da det afvikles i en browser har man ofte stadig et behov for at interagere med andre dele af siden og det gøres typisk ved at man nu interagere imellem C# og Javascript, hvilket nu er blevet langt lettere med indførelsen af dynamic i C#.
Jeg forudsætter selvfølgelig at du er klar over noget så basalt når du postulerer at kode Silverlight til daglig.
Men da det afvikles i en browser har man ofte stadig et behov for at interagere med andre dele af siden og det gøres typisk ved at man nu interagere imellem C# og Javascript, hvilket nu er blevet langt lettere med indførelsen af dynamic i C#.
Jeg forudsætter selvfølgelig at du er klar over noget så basalt når du postulerer at kode Silverlight til daglig.
#74
Nej, du kodede IronJScript, ikke JavaScript.
Det synes stadigvæk ikke at have noget med Silverlight at gøre overhovedet.
Nej, du kodede IronJScript, ikke JavaScript.
Mellem Silverlight og JavaScript, vil jeg nærmere sige (der er specifikke APIs til det).mstify (74) skrev:Men da det afvikles i en browser har man ofte stadig et behov for at interagere med andre dele af siden og det gøres typisk ved at man nu interagere imellem C# og Javascript
Kan du helt konkret, fortælle hvordan det er blevet nemmere? Fordi du slipper for at inputvalidere alt hvad du for fra JavaScript?mstify (74) skrev:hvilket nu er blevet langt lettere med indførelsen af dynamic i C#.
Det synes stadigvæk ikke at have noget med Silverlight at gøre overhovedet.
#75: Ah jeg tror jeg begynder at forstå hvad det er du så stædigt holder fast i nu, du adskiller sprogfeatures fra de underliggende teknologier meget stringent og fastholder at dynamic keywordet er en C# sprogfeature der som udgangspunkt ikke har noget med hverken Silverlight eller COM at gøre og hvis du vælger at se på det på den måde har du principielt ret, men så er det fordi du ikke ser det i en større sammenhæng.
I det større billede er pointen den at C# har udviklet sig til at være det klart mest anvendte sprog til .NET platformen i kommerciel sammenhæng, men da det er typestærkt har der været nogle naturlige ting det ikke har været helt så godt til i specielt interop sammenhæng. En af de meget væsentlige ting her er COM udvikling, som der laves rigtig meget af i .NET. En anden væsentlig ting i det historiske perspektiv var Microsofts store satsning på Silverlight og her var specielt Javascript og DOM interop nogle af de ting der var besværlige at gøre i et typestærkt sprog som C#.
Det er væsentlig at forstå i den her sammenhæng at det er uhyre kontroversielt at indføre dynamisk support i et ellers typestærkt sprog som C# og C# er så vidt jeg ved det første sprog nogensinde til at gøre det. Set fra et rent sprogligt perspektiv er det lidt noget rod, men C# er et meget pragmatisk sprog og det betyder at man har set utrolig meget på hvad behovet ude i erhvervslivet var - og her var der 2 meget gode argumenter for at gøre det, det ene var COM som dynamiske typer ville gøre det meget nemmere at kode op imod og det andet var Silverlight, som godt nok ikke var/er så anvendt, men tilgengæld ønskede Microsoft at pushe teknologien meget hårdt og derfor blev det også et væsentligt argument for at indføre supporten i C#.
Så når jeg taler om COM og Silverlight er hovedårsagerne til indførelsen af dynamic i C#, så er det fordi det er de teknologier der har drevet behovet for indførelsen og har resulteret i at vi nu har et sprog der er både typestærkt og typesvagt.
I det større billede er pointen den at C# har udviklet sig til at være det klart mest anvendte sprog til .NET platformen i kommerciel sammenhæng, men da det er typestærkt har der været nogle naturlige ting det ikke har været helt så godt til i specielt interop sammenhæng. En af de meget væsentlige ting her er COM udvikling, som der laves rigtig meget af i .NET. En anden væsentlig ting i det historiske perspektiv var Microsofts store satsning på Silverlight og her var specielt Javascript og DOM interop nogle af de ting der var besværlige at gøre i et typestærkt sprog som C#.
Det er væsentlig at forstå i den her sammenhæng at det er uhyre kontroversielt at indføre dynamisk support i et ellers typestærkt sprog som C# og C# er så vidt jeg ved det første sprog nogensinde til at gøre det. Set fra et rent sprogligt perspektiv er det lidt noget rod, men C# er et meget pragmatisk sprog og det betyder at man har set utrolig meget på hvad behovet ude i erhvervslivet var - og her var der 2 meget gode argumenter for at gøre det, det ene var COM som dynamiske typer ville gøre det meget nemmere at kode op imod og det andet var Silverlight, som godt nok ikke var/er så anvendt, men tilgengæld ønskede Microsoft at pushe teknologien meget hårdt og derfor blev det også et væsentligt argument for at indføre supporten i C#.
Så når jeg taler om COM og Silverlight er hovedårsagerne til indførelsen af dynamic i C#, så er det fordi det er de teknologier der har drevet behovet for indførelsen og har resulteret i at vi nu har et sprog der er både typestærkt og typesvagt.
Du kan stadigvæk ikke bruge dynamics til at arbejde med COM.
Men du kan bruge dynamics i resten af koden. Bare ikke til den del hvor du arbejder med COM.
Og jeg tror nu stadigvæk mere på at dynamics blev introduceret i C#, for at have interop med dynamiske .NET sprog som IronPython. Og ikke særlig meget at gøre med Silverlight.
Men ellers er vi ved at være på samme spor nu.
Men du kan bruge dynamics i resten af koden. Bare ikke til den del hvor du arbejder med COM.
Og jeg tror nu stadigvæk mere på at dynamics blev introduceret i C#, for at have interop med dynamiske .NET sprog som IronPython. Og ikke særlig meget at gøre med Silverlight.
Men ellers er vi ved at være på samme spor nu.
#77: Jeg tror du adskiller tingene for hårdt igen når du siger at det ikke har noget med COM at gøre - jeg tror problemet er at du kigger på det med meget akademiske briller.
Dynamic reducerer drastiskt kompleksiteten og mængden af den skrevne kode der skal til når du laver COM udvikling og det er det der har retfærdiggjort indførelsen - at det så rent sprogteknisk foregår i runtimen og ikke som sådan har noget med COM interop i sig selv at gøre er kun interessant fra et teoretisk/akademisk perspektiv, fra et pragmatisk/praktisk perspektiv er betydningen ret stor.
Her er et simpelt eksempel:
http://www.intertech.com/Blog/post/Simple-COM-Inte...
Bemærk at Dynamic mappingen sker implicit for COM objekter.
Dynamic reducerer drastiskt kompleksiteten og mængden af den skrevne kode der skal til når du laver COM udvikling og det er det der har retfærdiggjort indførelsen - at det så rent sprogteknisk foregår i runtimen og ikke som sådan har noget med COM interop i sig selv at gøre er kun interessant fra et teoretisk/akademisk perspektiv, fra et pragmatisk/praktisk perspektiv er betydningen ret stor.
Her er et simpelt eksempel:
http://www.intertech.com/Blog/post/Simple-COM-Inte...
Bemærk at Dynamic mappingen sker implicit for COM objekter.
Så endeligt begynder du at blive konkret. Men nej, jeg kigger på ingen måde på det med akademiske briller. Og jeg har programmeret .NET længe.
At undgå en række typecasts er fint, men problematikken er at der så modsat ikke er nogen statisk validering, eller intellisense.
Så jeg er ikke nødvendigvis enig i at det er bedre.
Optional parameters er da den største forbedring for læsbarheden.mstify (78) skrev:Her er et simpelt eksempel:
At undgå en række typecasts er fint, men problematikken er at der så modsat ikke er nogen statisk validering, eller intellisense.
Så jeg er ikke nødvendigvis enig i at det er bedre.
#79: Og i det mindste lader du nu til at anerkende at det benyttes i den sammenhæng, vi gør fremskridt :)
Og nu er det jo bare et eksempel og i den virkelige verden kan der findes meget grellere eksempler hvor dynamic gør det meget mere simpelt. Det mest interressante i ovenstående eksempel er den langt mere simple måde data i cellerne kan tilgåes og sættes på - hvis vi nu forestiller os at vi skulle lave en masse celle-arbejde i Excel-eksemplet, så ville dynamics imo gøre det lettere, mere intuitivt og øge læsbarheden af koden.
Men der er fordele og ulemper og om man bør gå typestærkt eller typesvagt i sådanne tilfælde er en helt anden diskussion - men C# giver os valget.
Og nu er det jo bare et eksempel og i den virkelige verden kan der findes meget grellere eksempler hvor dynamic gør det meget mere simpelt. Det mest interressante i ovenstående eksempel er den langt mere simple måde data i cellerne kan tilgåes og sættes på - hvis vi nu forestiller os at vi skulle lave en masse celle-arbejde i Excel-eksemplet, så ville dynamics imo gøre det lettere, mere intuitivt og øge læsbarheden af koden.
Men der er fordele og ulemper og om man bør gå typestærkt eller typesvagt i sådanne tilfælde er en helt anden diskussion - men C# giver os valget.
Windcape (46) skrev:Nej. Silverlight er et seperat subset af .NET, med egne APIs (som tit er forskellige, eller begrænsede fra .NET)arne_v (44) skrev:.NET er det samme via SL
Java Applets er ikke et seperat subset af Java. Det er ret stor forskel!
Der er et par forskelle:
- Java genbruger binary kode, .NET genbruger source kode til nye binaries
- Java bundler i installer, .NET har to installere
Men sikkerheds problemet er det samme.
Og i Java kan man også vælge hvilken version der skal bruges af applets, men det kræver nok at man læser en readme.txt eller lignende for at finde vejledningen.
Windcape (46) skrev:
Overhovedet ikke. En af de typiske .NET 4 ting man bruger til COM er optional-parameters, som har været i .NET siden 1.0 (pga. VB.NET), men kun i C# siden version 4.
Dynamics er stort set ikke brugt, udover til integration med JavaScript, og andre DSL'er.
Dynamics er særdeles nyttig og anvendt til COM.
Dynamics kan også bruges med dynamic typed languages, men det er sjældent anvendt. Ved mixe dlanguage apps kalder man næsten altid fra higher level til lower level languages. Det giver god mening at lade IronPython kode kalde C# kode, men ikke nær så meget mening at lade C# kode kalde IronPython kode.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund