(I first wrote most of this about 3 weeks ago, but never got a chance to finish and post it. I’ll be posting something else about “My” is a few days, so I wanted to post this first.)
When I first heard about “My” Classes (list of classes) planned for Whidbey/Visual Studio 2005, I thought it sounded a little too cutesy for my taste: “That’s nice and it should help some people get started, but I don’t think anyone will do any serious programming with it.” And I’ve even heard some C# developers pooh-pooh “My” as something to make .NET easy enough for VB developers such as here.
However, once I read Duncan Mackenzie’s article in May 2004 MSDN Magazine entitled “Navigate the .NET Framework and Your Projects with “My”” and all I could say was wow! I was struck by a few things:
- “My” is just a layer on top of the existing framework — its the same code you’d probably write anyway — and returns instances of framework classes when appropriate so you don’t really lose anything by using “My” when you don’t need more power or flexibility.
- Recognition is easier than recall: The “My” hierarchy makes it much easier to find the 20% of the functionality you use 80% of the time. You don’t have to explicitly remember all those features as you would have in VB6; if you have a vague memory of functionality, just navigate the hierarchy to find it.
- By implementing a hierarchy to simplify basic use of the existing framework, Microsoft exposed “holes” in the functionality provided by the framework. This led to Microsoft implementing useful functionality they might not otherwise have put on their priority list.
Point #2 leads me to believe that in some ways VB 2005 might actually be easier to learn than was VB6. Point #3 makes me think the “My” hierarchy brought positive improvements beyond VB; all he way to the .NET framework itself.
P.S. Some people are using the term “speed dial” to describe the “My” classes. IMO that analogy doesn’t quite fit, and I think it discredits the “My” classes by implication. FWIW.