Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
Here’s a question I recently got about VBScript, where by "recently" I mean August 28th, 2003. This code works just fine:
Set myObject = CreateObject("myObject")myObject.myName = "Eric" WScript.Echo myObject ' myName is the default property, so prints "Eric"
But myObject = "Robert" doesn't set the default property, it sets the variable to the string.
In a strongly typed language such as VB6 the compiler can look at the compile-time types of the left and right sides of an assignment and determine that the type of the left hand side is an object, the right hand side is a string, and the object has a default property which is a string. The VB6 compiler can then generate the appropriate code to assign the string to the default property.
But what if you wrote a VB6 program using only variants? When the compiler sees
I hear you exclaiming "The fact that a difference in available type information leads to a difference in run-time behaviour violates a basic principle of programming language design! Namely, the principle that late-bound calls have exactly the same semantics as early-bound calls!"
Indeed, as I've mentioned before, VB6 and VBScript violate this principle in several places. Default properties were, in my opinion, a bad idea all around, for this and other reasons. They make the language harder to parse and hence harder to understand. In particular, parameterless default properties make very little sense in VBScript. However, we are stuck with them now.
However, I should call out that there are some things we can do at runtime. Suppose
Or suppose you have an object
x = Baz.Table(1).Blah
But why? In this case we do not have enough compile-time information to determine that we really should call
then invoke the default property with the argument list. Strange but true.
Perhaps unsurprisingly, not very many people know about that rule! This is yet another reason to never, ever write your own implementation of
I found this site very useful.
we can learn a lot about VBScript.
Thanks for shedding a little light on a mysterious subject. Where can I find more detailted information on how the default property semantics in VB6? I am trying to interpret some code that has a subroutine with arguments of type Control being passed to functions that take Variant.
Public Function foo(ctl As Control) As Boolean
If IsNumeric(ctl) = False Then
ctl = Format$(ctl, s_precision)
How does VB6 decide when to pass a reference to the object and when to pass a reference the default property.
Is there a formal specification for the VB6 language anywhere?
Thanks for this information - it has really helped me understand some issues.
I am trying to upgrade a VB6 app to dot net - and the new app gets called from VBScript - so the behaviour between VB6 and .NET must match - but this will not work and it relates to issues that you have detailed above.
I have created a class in dot net with a default property based on iCollection interface - this works fine - I can enumarete fine and referance it like NewCollection(1).TestProp - without issues - but when this collection is returned as a property from another object it does not work. - ie.
ApplicationClass.NewCollection(1).TestProp does not work - but ApplicationClass.NewCollection.Item(1).TestProp does work - and so does "Set its = ApplicationClass.NewCollection" and than its(1).TestProp
Also noticed that ApplicationClass.NewCollection()(1).TestProp does work.
Is there anyway of getting .NET to behave the same way as what VB6 does - are there some attributes that I can apply to correct this behaviour??