Here’s an interesting read on something coming down the pike with Visual Studio. Basically, it’s a customizable shell of VS that would theoretically allow you to build you’re own Visual Studio, language and all.
Likely, it’ll be on a complexity scale of integrating VBA into your app (anyone remember that 300-armed, greased-up monster squid?), but still, very interesting.
Another interesting read on Extension Methods coming in VB9. I’ve wondered why something like this hasn’t been in VB since the very early days of classes (anyone remember VB4?). Why, oh, why have I never been able to create a method like:
Public Function MyOwnReplace(Self as string, Arg as string) as String Extends String
Return Blah(Arg)
End Function
and then use it by calling the function method off of any ol’ string variable…
Debug.Print MyString.MyOwnReplace(Arg)
Maybe this is a contrived example, but the Dynamic languages concept of extending existing objects is something that just belongs in VB.
5 Comments
Educate me please… why is a method intrinsically better than a direct function call?
Don’t methods impose additional overhead (i.e. the object reference itself) whereas a function is simply a reference to a jump table?
If you need a method for interoperability, isn’t that what classes are for?
Well, my example could have probably been better. You’re absolutely right about methods and function calls.
The idea behind these "extension methods" is that you can extend already existing object interfaces, without necessarily having to inherit from them (and in the case of some non-inheritable objects, like strings, you could still extend the object, even though you can’t inherit from it).
Plus, in many cases, you might not want to create a "ExtendedString" class that inherits from String (if you could) because then you’d have to replace all instances of "String" with the new "ExtendedString" in your code.
Basically, extension methods just give you a way to extend an existing object type without having to modify it or inherit from it.
The idea is slick, my explanation, maybe not so much.
Ah! I think I see. It’s a bit like late-binding an object? As slow as that process can be at runtime, it’s still a very cool technology, and sometimes the ONLY way to keep a legacy app functioning.
Would this new .methodology (sorry) provide the same flexibility but with enhanced performance?
However, this would just be yet another primitive 98% of the dev community will miss out of igorance. The command set for VB is already freekin huge. Instead, I’m thinking the VB9 development team should just give up and incorporate a generic Run command with a bazillion parameters. The syntax should be very similar to the old Hayes modem AT command set. The documentation would be one 600,000 line HTML page, in .CHM format (of course). Then VB10 would "clean it up" by making all the commands case-sensitive or something.
Whoops, I’m ranting. Forgot to take my pills.
I see it as very much like Late-binding, but with intellisense, and it’s actually early bound from a compiler perspective, from what I can tell so far.
The main use I’ve seen so far is in extending Data objects dynamically. This is a main feature in Linq, though I’m just not terribly familiar with it yet.
But damn, sounds awfully handy in any case.
Hey, about that Hayes Command set idea. They already did that, sort of. Remember the MCI Media command strings? How about
SendMCIString "open cdaudio alias cd shareable"
SendMCIString "set cd door open"
SendMCIString "close cd"
Ah, the good ol’ days. Just slap "AT DT" in front, and you’re ready to go!
*shudder*
I’d comment that SendMCIString was an incredibly lazy solution, but SOMEBODY spent a long time writing a parser that could handle that stuff. Lazy? Not even.
My hat’s off to you, mysterious SendMCIString developer. They’re probably assigned to the PowerShell dev group now…