What's for VB.NET in the Future, interesting to see...
By being momentarily pissed off to the level of job I needed to do with classes working with DB and business logic in a project, I made suggestion in Connect, a while ago
Ability to specify a default method for object instance which is called when any or certain method/properties will be accessed
"For VB team (why not for C# too :-) )
Writing logic to check object's state when properties are accessed can cause quite a bit repeated code, because at least you need to duplicate the call on every property accessor.
Certainly there are other ways around this which usually is checking the state then on some method, but not on the property accessor (design guidelines state that property accessor shouldn't throw an exception), but it would be great if compiler would be able to inject a call to a "default" method which will be called when any or given property is accessed.
Properties are methods under the covers and I believe they should be allowed to throw exceptions if state of the object demands for it. For example in my scenario, it represenst an object deleted from database. One must not use the object anymore because it doesn't really exist...
I got a response quite fast from Jonathan Aneja, Program Manager on VB Team, here's what he said:
Thanks for taking the time to file this suggestion. I've got some good news and bad news for you. The good news is the scenario you mention is one we've been thinking about a lot lately, and we have some ideas on how to address this in a big way.
The bad news is the timeframe we're thinking of for this feature is actually two releases away, not one. This is part of a much larger feature we're building that's going to take a while to build.
I'm going to resolve this as "By Design" for now, but rest assured this scenario is high on our list."
Oh, and I got also a nice community comment that I'm looking for aspect-oriented programming (with link to: http://www.bodden.de/tools/aop-dot-net/), thanks for that btw!
Point is that it's actually pretty nice to know that these things are also thought at MS. Not that I mean component and 3rd party vendors providing these as products should not exist, but I've always loved the idea that I have all the stuff in the one and only development environment, plus of course, what I use works as a product. I'm definately going to have a look at aspect-oriented programming, it indeed seems what I'm looking for. But it's important to know that the future of my toolset is going to evolve - and with VS201x I still might see something groundbreaking cool in VB.NET. :-)
When I asked the permission from Jonathan to post his comment publicly, he thought that there might not actually be much to see in his response, but I disagree. Mostly because knowing that MS thinks these scenarios also basically calls for feedback too, at the early stage (involving community in design-related tool development etc is better to happen sooner than later - not least because there are almost as many opinions as commenters)). So it's good to know there's design work going on, which community can comment on, at least it's targeted at something, even though community doesn't know what they're commenting (or MS does based on their comments). :-D
Certainly, this is something that language team is now designing for the future, so how wide can that feature be, without it falling out of the context or needing already coordination and cowork with other teams? Hard to say as Jonathan didn't tell more about what they are thinking at the moment. But I hope they reveal it on one day. :-)
What comes to the idea itself, what I proposed, is one thing I'm looking for eagerly and it's great they gonna solve it somehow (although years will pass before it's out), but is there something else someone would want to see in VB.NET in the Future? Suggesting that in Connect might be a good idea.