Partial Classes

Partial Classes are a new feature of Visual Studio 2005. Basically they allow you to spread code across multiple code files. I have heard a lot of criticism about partial classes, mainly the whole "If you need partial classes then your class is too big".. Not so.

A good use for partial classes is with typed datasets. A lot of developers I have talked to use typed datasets for all of there Business Objects. The only problem is when you modify the database, then re-generate the typed datasets, any custom code is lost. By having the additional code defined in a separate file, this problem can now be avoided.

My only complaint with partial classes actually has to do with the functionality of visual studio 2005, more than partial classes themselves. My development team has a standard in place, where developers are required to use Overrides where possible instead of events. An example of this is using OnLoad override instead Form.Load event. Now, when you double click on a form in VS.NET 2k5, VS automatically creates a Form.Load event handler. In VB.NET, all you have to do is delete the actual event handler and all is fine. C# is a different matter. Not only do you now have to delete the actual Callback method, you now have to locate the "Hidden by Default" partial class containing all the designer code and remove the declaration for the Event Handler.

I actually dropped by the VS beta site http://lab.msdn.microsoft.com/vs2005/ and left a suggestion to allow the user to override the action performed when double clicking, but unfortunately I was told it was too late in the development process to look at that.. Hopefully we will see a change in Orcas??

Write Only Properties?

I was recently going through a colleagues code and noticed that in several places he had added write only properties. i.e. Set without a Get

In this case, he just happened to be a little on the lazy side, but it got me wondering, how often do people actually need to use write only properties. What are the reasons for having them?

The only possible thing I can think of would be security (all be it very limited), but surely there would be very few places where this sort of functionality is required.

I'm interested to hear other peoples feedback on this.

A new Addition

Last wednesday saw the arrival of the latest addition to my little family, Alisha Jay de Bear.
Now the tally sits at 1 wife, 2 girls, 0 boys. I feel the odds are stacked against me :)

Back where we started?

Yesterday a bug was uncovered in an old application what was written in VB6. The bug had to do with forms not being unloaded because of some of the nice features in VB6. I'm talking about the Global Forms collection and the Default Form Instances.

Both of these features where useful, but lead to a large and dangerous group of people who produced a lot of bad, buggy software.

Until this recent event I was very impartial to the fact that the VB.NET dev team decided to re-introduce the Default Form instances into whidbey. Now I'm not so sure.

Are we going to end up with hoards of ex VB6 developers writing apps in VB.NET using the default form instance. I think yes.

I suspect the real reason behind this decision is to make the transition of VB6 developers to .NET a little easier. I think however, that we could well end up with many of the old habits that proved to be a problem in VB6 reappearing in VB.NET. This in turn could easily lead to VB.NET regaining the old stigma of VB6 in the general development community.

I for one am more than a little worried.