Late-Binding Suggestion for VB

Steven Lees, the group program manager for Visual Basic at Microsoft, wanted to hear more about my thoughts on Linq after reading my blog post on the same topic.

I told him that I like the direction that Visual Basic is going, providing a friendly and accessible syntax for SQL and XML.

I also like the opposite direction that C# is going to regarding Linq, because I use C# for building sophisticated commercial applications, where the majority of the time is spent testing rather than developing. I want the compiler to verify as much of my code at compile time as possible. In C#, I am also more likely to build queries in functional form because the transformations from SQL syntactical sugar appear to be suboptimal in complicated queries, mostly when querying objects but probably not for databases, in which queries have a second chance at optimization in the server.

VB as a Scripting Language

Because of the friendly syntax, background compilation, better edit-and-continue, and the late-binding, Visual Basic seems like a good choice for “glue-code” applications not based on complex algorithms—stuff that doesn’t require lots of testing. Visual Basic may be more promising for me in building scripts—a potential replacement for Perl or Python. Windows Scripting Host doesn’t support any of the .NET languages; I would like to see on-the-fly compilation of both C# and VB script files ala NScript with support for libraries.

However, to be a real replacement for Perl and Python and other dynamic languages, Visual Basic probably should support some expando properties (built using dictionary objects from Erik Meijer’s Paper on Dynamic and Static Typing) in addition to latebinding and other features proposed for VB 9.

Extensible Late Binding

VB 9 supports customized late-binding for XML, which is rather cool, and provides a XPath-like notation as found in COmega.

• Normal latebinding maps obj.Property to obj.GetType().GetProperty().GetValue(obj, null), where obj is of static type Object.
• XML latebinding maps element.Property to element.Element(“Property”, where element is of static type XElement.

I suggested that the late-binding mechanism be generalized, maybe through a “dot” overload operator, so that other objects can expose their own unique late-binding mechanism to enable a simpler, more natural syntax and duck typing. Some examples are…

• Dictionaries. For hashtables and other dictionaries that have string-based keys, dict.Property would behave the same as dict[”Property”]
• Collections<T>. Collection.Property could perform type-lifting and return an enumeration (IEnumerable<T>) of property values for each element in the collections. It would map to either collection.Select( it => it.Property ) or collection.SelectMany( it => it.CollectionProperty ) depending on whether a property returns a collection or not.
  • Type-lifting is completely typed and early bound
  • Object accessors would become more XPath-like, bridging the gap between object and XML latebinding. XML latebinding works a little different from traditional property accessors in that it returns an IEnumerable sequence..
• Others. Nullable<T> and other classes could expose properties and methods of  the underlying values they represent. DataReader could allow access to records by name.

The new dynamic identifiers feature, obj.(string expression), could work easily with all these late-binding mechanisms. Integration with Dynamic interfaces, however, would require additional changes to the current proposal. Currently, declaring an object to be of a dynamic interface type causes the underlying type of the object to be hidden. So, XElements and other objects would lose their special late-binding behavior and revert to reflection.

Comments

[Ingo Rammer]

Very nice idea! I haven't though through all the implications (of course ;-)), but the idea of an overloadable dot-operator seems to be quite nice.

[Ayende Rahien]

I would like to see something like Boo's IQuackFu.

This is an interface that you can implement and it transform a call to:

val = dic.Prop;

val = dic.QuackGet("Prop");

dic.Prop = 3;

dic.QuackSet("Prop",3);

dic.Method(3);
dic.QuackInvoke("Method",3);

It's a really cool way to mess with what will happen in runtime, and completely user extensible.

[Jonathan Allen]

"I suggested that the late-binding mechanism be generalized, maybe through a “dot” overload operator, so that other objects can expose their own unique late-binding mechanism to enable a simpler, more natural syntax and duck typing. Some examples are…"

Maybe instead of using a dot, it should use the "bang" syntax from VB6.

oRS("SomeField") => oRS!SomeField

[secretGeek]

The main difference I can see (currently...) between VB.next and a 'scripting language' is the ease of deployment.

.net deployment is tailored toward long-term, secure deployment, while scripts are more of a hacker's playground.

i haven't read about any changes or advances in this area though -- perhaps i'm overloooking some. i guess when the .net framework is natively included on most machines, a large portion of the deployment hurdle will already be cleared.

[Wesner Moise]

VB 9 actually supports ! for dictionary member access, so it already works with hashtables and the like