I think an obvious disadvantage is that it shares syntax with calling Shared properties/methods. It's very easy to get those things confused. The difference between Shared and instance is a hard enough concept to explain to new programmers when it's not being mixed up with a hidden instance.
I suppose an advantage is shorter syntax. But I personally refuse to use it when I'm using VB.NET.
I think I'm biased against it, because I had no idea it was even there for a while. I remember telling someone flat out that their code shouldn't even compile, and I was shocked when it did! Of course, it didn't work, but it compiled.
Actually, I'm curious how a default instance actually works. Is it instantiated upon execution, or the first time it's called, or every time it's called? If a form doesn't provide a default constructor, what happens?
Also, I suppose the good/bad relates to using the Default Instance?
This post has been edited by insertAlias: 26 January 2011 - 03:09 PM
I think this was added later to help the VB6 people move up to VB.Net. If I remember correctly, in the first release of VB.Net, you could not use a forms default instance. If you remember, there was a lot of animosity when VB6 programmers started using VB.Net and things just didn't work like they thought it would. Hell, I was one of them. I actually struggled to move to .Net because of all the changes from my knowledge of VB6.
I actually think if MS would have stuck to their guns, people would have came around and learned the proper methods but I'm sure marketing had a lot to do with these types of decisions. We can increase sales if we'll succumb to their gripes.
I think the real problem is, the default instance is primarily how students are taught to access the form. Let alone all the other legacy methods from the VisualBasic namespace.