Jeroen’s weblog

I wrote a lot of (D)COM-components back in the ’90s and early 2000s and one of the things I like about VB was Automation. I know IDispatch was not a VB-specific interface, but since VB implemented it by default I always associate the two. For those that never used it, the short description of IDispatch is that it contains an Invoke-method, that you simply pass a string and say: “See if you have a method with that name, if you do, call it!” This made it possible to use VB-components in late bound scripting languages like VBScript.

Yesterday I read a post by Martin Fowler on implicit interface implementation which proposes that languages gain (or regain, in VB’s case) some of that IDispatch-like behaviour. A follow-up to it by Wesner Moise mentions that VB9 will support dynamic interfaces, which is basically a way to formalize compile-time assumptions about objects you encounter at runtime. It’s like casting the object to an interface that it might not explicitly implement. The actual compatibility check is performed at runtime, when an actual call to a method in the dynamic interface is made. This is also known as duck typing.

While browsing the VB9 overview, another similar feature caught my attention that basically provides what IDispatch used to: dynamic identifiers. You can provide a string and ask the object to execute a method with that name. This more or less turns VB.NET into a dynamically typed language, depending on how everything ends up working (I can imagine that there are some limitations that are not apparant in the example the overview provides). I think it would be a good direction for VB.NET to take, since the differences between the major .NET-languages have been relatively minor up until now.