And The #1 Reason Why Silverlight *ROCKS*...

by M. David Peterson

No legacy API's to support.

(or in other words, theres one way to do something, and the way to do that something is the *CORRECT* way to do that something.)

Dear Microsoft Silverlight team,

*PLEASE* don't given into pressures to provide feature support for *ANY* other reason than it's absolutely mandatory to provide it. I'm beginning to truly understand just how wonderful of a language within a language LINQ truly is. Please leave it alone. :)

Thanks in advance,

Your *BIGGEST* fan

2 Comments

Andrew Shebanow
2007-06-04 12:28:03
No legacy APIs to support? .NET 1.0 went final in 2002, version 3 was released with Vista, and CoreCLR has to maintain compatibility with that whole codebase...
M. David Peterson
2007-06-04 13:35:01
>> No legacy APIs to support?


Yup.


> .NET 1.0 went final in 2002,


Five years ago.


> version 3 was released with Vista,


Couple of months ago.


> and CoreCLR has to maintain compatibility with that whole codebase...


No it doesn't. What gave you that silly assumption. Have you tried to compile an existing .NET project code base against the Silverlight API. While the CoreCLR might be a complete Common Language Runtime engine, the API *IS NOT* the CLR. The CLR knows one thing and one thing only: CIL. The API, or .NET Framework Class Library, is something completely different. While the FCL is compiled into CIL, that doesn't mean that the Silverlight API includes the entire FCL as it exists today, which is what I am referring to.


For example: The system.Xml.Core library includes XmlReader and XmlWriter. No XmlTextReader, XmlTextWriter, etc... which is what I am referring to when I state "legacy API's". There are times when these classes make sense, but in the context of a web browser I can't think of a single reason why you would need them. Can you? The same is true about System.Collections.*.* There's a lot of really nice things that make sense in the context of a full desktop application, but are really not all that necessary in the context of a light weight browser app.


All of the above is what I am referring to. And five years is MORE than enough time to consider a good portion of the .NET FCL legacy.