Fabulous Adventures In Coding : Scripting

The void is invariant

Eric Lippert — Mon, 29 Jun 2009 17:30:00 GMT

[UPDATES below]

A while back I described a kind of variance that we’ve supported since C# 2.0. When assigning a method group to a delegate type, such that both the selected method and the delegate target agree that their return type is a reference type, then the conversion is allowed to be covariant. That is, you can say:

Giraffe GetGiraffe() { … }
…
Func<Animal> f = GetGiraffe;

This works logically because anyone who calls f must be able to handle any animal that comes back. The actual method claims to only return animals, and in fact, makes the stronger claim to only return giraffes.

This works out in the CLR because the bits that make up a reference to an instance of Giraffe are exactly the same bits that make up a reference to that Giraffe interpreted as an instance of Animal. We can allow this magical conversion to happen because the CLR guarantees that it will all just work out without going in there and having to futz around with the bits.

This is why this trick only works with reference types. A method that returns, say, a double cannot be converted via a covariant conversion to a delegate type that expects the method to return an object. Somewhere there would have to be code emitted that takes the returned double and boxes it to object; the bits of a double and the bits of a reference to an object boxing a double are completely different.

But why doesn’t this trick work with void types? Here we have a method that returns some sort of success or failure code. Maybe we don’t care what it returns.

static bool DoSomething(bool b)
{
if (b) return DoTheThing();
else return DoTheOtherThing();
}

Action<bool> action = DoSomething;

This doesn’t work. Why not? The caller of the action is not even going to use the returned value, so it doesn’t matter one bit what it is! Shouldn’t “void” be considered a supertype of all possible types for the purposes of covariant return type conversions from method groups to delegate types?

No, and I’ll tell you why.

Consider what happens when you do this:

bool x = DoSomething(true);

We spit out IL that does the following:

(1) put true on the IL stack – the stack gets one deeper
(2) call DoSomething – the argument is removed from the stack and the return value is placed on the stack. Net, the stack stays the same size as before
(3) stuff whatever on top of the stack into local variable x – the stack now returns to its original depth.

Now consider what happens when you do this:

DoSomething(true);

We spit out IL that does the first two steps as before. But we cannot stop there! There is now a bool on the IL stack which needs to be removed. We generate a pop instruction to represent the fact that the returned bool has been discarded.

Now consider what happens when you do this:

action(true);

The compiler believes that action is a void-returning method, so it does not generate a pop instruction. If we allowed you to stuff DoSomething into the action, then we would be allowing you to misalign the IL stack!

But didn’t I say “the stack is an implementation detail?” Yes, but that’s a different stack. The CLI specification describes a “virtual machine” which passes around arguments and returned values on a stack. An implementation of the CLI is required to make something that behaves like the specified machine, but it is not required to do so in any particular manner. It is not required to use the million-bytes-per-thread stack supplied to each thread by the operating system as its implementation of the IL stack; that’s a convenient structure to use, of course, but it’s an implementation detail that it does so.

(As an aside: when we implemented the script engines, we also first specified our own private stack-based virtual machine. When we implemented it, we decided to put the information about “return addresses” – that is, “what code do I run next?” on the system stack, but we put arguments and return values of script functions in a stack-shaped block of memory that we allocated on our own. This made building the JScript garbage collector easier.)

In practice, the jitter uses the system stack for some things and registers for other things. Return values are actually often sent back in a register, not on the stack. But that implementation detail doesn’t help us out when deciding what the conversion rules are; we have to assume that the implementation can do no more than what the CLI specification says. Had the CLI specification said “the returned value of any function is passed back in a ‘virtual register’” rather than having it pushed onto the stack, then we could have made void-returning delegates compatible with functions that returned anything. You can always just ignore the value in the register. But that’s not what the CLI specified, so that’s not what we can do.

[UPDATE]

A number of people have asked in the comments why we do not simply generate a helper method that does what you want. That is, when you say

Action<bool> action = DoSomething;

realize that as

static void DoSomethingHelper(bool b)
{
bool result = DoSomething(b); // result is ignored
}
...
Action<bool> action = DoSomethingHelper;

We could do that. But where would you like the line to be drawn? Should you be able to assign a reference to a method that returns an int to a Func<Nullable<int>>? We could spit a helper method that converts the int to a nullable int. What about Func<double>? We could spit a helper method that converts the int to a double. What about Func<object>? We could spit a helper method that boxes the int, unexpectedly allocating memory off the heap every time you call it. What about a Func<Foo> where there is a user-defined implicit conversion from int to Foo?

We could be spitting arbitrarily complex fixer-upper methods that would seamlessly "do what you meant to say", and we have to stop somewhere. The exact semantics of what we do and do not fix up would have to be designed, specified, implemented, tested, documented, shipped to customers and maintained forever. Those are costs. Plus, every time we add a new conversion rule to the language we add breaking changes. The costs of those breaking changes to our customers have to be factored in.

But more fundamentally, one of the design principles of C# is "if you say something wrong then we tell you rather than trying to guess what you meant". JScript is deliberately a "muddle on through and do the best you can" language; C# is not. If what you want to do is make a delegate to a helper method then you express that intention by going right ahead and making that method.

Iterators at the Summer Games

Eric Lippert — Fri, 26 Jun 2009 17:09:00 GMT

Ed "Scripting Guy" Wilson was kind enough to ask me to be a guest commentator at this years Summer Scripting Games, which have just completed.

I've been working on a series for this blog about some unusual cases in the design of the "iterator block" feature in C# 2.0; this bit from my commentary is going to be germane to that series. I thought I'd post it here as an appetizer before we get into the main courses of the series. The series on iterators will probably run throughout July.

The problem for event ten of the scripting games was to write a script which changes the priority of every new process that has a particular name.

***********

There’s an odd thing that you learn when working on developer tools: The people who design and build the tools are often not the experts on the actual real-world use of those tools. I could tell you anything you want to know about the VBScript parser or the code generator or the runtime library, but I’m no expert on writing actual scripts that solve real problems. This is why I was both intrigued and a bit worried when the Scripting Guys approached me and asked if I’d like to be a guest commentator for the 2009 Summer Scripting Games.

I wrote this script the same way most scripters approach a technical problem that they don’t immediately know how to solve; I searched the Internet for keywords from the problem domain to see what I could come up with. Of course, I already knew about our MSDN documentation, I had a (very) basic understanding of WMI, and I knew that the Scripting Guys had a massive repository of handy scripts.

My initial naïve thought was that I would have to go with a polling solution; sit there in a loop, querying the process table every couple of seconds, waiting for new processes to pop up. Fortunately, my Internet searches quickly led me to discover that process startup events can be treated as an endless collection of objects returned by a WMI query.

That got me thinking about the powerful isomorphism between events and collections.

A collection typically uses a “pull” model — the consumer asks for each item in the collection one at a time as needed, and the call returns when the item is available. Events typically work on a “push” model — the consumer registers a method that gets called every time the event fires. But not necessarily; the WMI provider implements events on a “pull” model. The event is realized as a collection of “event objects.” It can be queried like any other collection. Asking for the next event object that matches the query simply blocks until it is available.

Similarly, collection iterators could be implemented on a “push” model. They could call a method whenever the next item in the collection becomes available. The next version of the CLR framework is likely to have standard interfaces that represent “observable collections”, that is, collections that “push” data to you, like events do. The ability to treat events as collections and collections as events can lead to some interesting and powerful coding patterns.

***********

The rest of the solution and analysis is here.

Have a good weekend!

It Already Is A Scripting Language

Eric Lippert — Wed, 24 Jun 2009 18:07:00 GMT

My recent post about the possibility of considering maybe someday perhaps adding "top level" methods to C# in order to better enable "scripty" scenarios generated a surprising amount of immediate emphatic pushback. Check out the comments to see what I mean.

Two things immediately come to mind.

First off, the suggestion made by a significant number of the commenters is "instead of allowing top-level methods, strengthen the using directive." That is, if you said "using System.Math;" then all the static members of that class could be used without qualification.

Though that is a perfectly reasonable idea that is requested frequently, it does not actually address the problem that top-level methods solve. A better "using" makes things easier for the developer writing the call. The point of top-level methods for scripty scenarios is to make it easier on the developer writing the declaration. The point is to eliminate the "ritual" of declaring an unnecessary class solely to act as a container for code.

Second, and more generally, I am surprised by this pushback because of course C# already is a scripting language, and has had this feature for almost a decade. Does this code fragment look familiar?

<%@ Page Language="C#" %>
<script runat="server">
void Page_Load(object sender, EventArgs e)
  {
      // whatever
  }
</script>
...

Where's the class? Where are the using directives that allow "EventArgs" to be used without qualification? Where's the code that adds this method group to the event's delegate? All the ritual seems to have been eliminated somehow. That sure looks like a "top-level method" to me.

Of course we know that behind the scenes it isn't any such thing. ASP.NET does textual transformations on the page to generate a class file. And of course, we recommend that you use the "code behind" technique to make a file that actually contains the methods in the context of an explicit (partial) page class, to emphasize that yes, this is a class-based approach to server-side processing.

But you certainly do not have to use "code behind". If you're an ASP traditionalist (like me!) and would rather see C# as a "scripting language" that "scripts" the creation of content on a web server, you go right ahead. You can put your "top level" methods in "script" blocks and your "top level" statements in "<% %>" blocks and you'll thereby avoid the ritual of having to be explicit about the containers for those code elements. The ASP.NET code automatically reorganizes your "script" code into something that the C# compiler can deal with, adding all the boring boilerplate code that has to be there to keep the compiler happy.

But consider now the burden placed upon the developers of ASP.NET by the language design. Those guys cannot simply parse out the C# text and hand it to the C# compiler. They've got to have a solid understanding of what the legal code container topologies are, and jump through hoops -- not particularly difficult hoops, but hoops nevertheless -- to generate a class that can actually be compiled and executed.

This same burden is placed upon every developer who would like to expose the ability to add execution of end-user-supplied code to their application, whether that's in the form of adding extensibility via scripting, or by enabling evaluation of user-supplied expressions (such as queries). It's a burden placed on developers of productivity tools, like Jon Skeet's "snippet compiler", or LINQPad. It's a burden on developers who wish to experiment with REPL-like approaches to rapid development of prototypes, test cases, and so on.

I am not particularly excited about the convenience of the ability to save five characters by eliding the "Math." when trying to calculate a cosine. The exciting value props are that we might be able to lower the cost of building tools that extend the power of the C# language into third-party applications, and at the same time enable new ways to rapidly experiment and develop high-quality code.

Of course we do not want to wreck the existing value props of the language in doing so; as I said last time, we also believe that there is huge value in the language design naturally leading professional, large-scale application developers towards building well-factored component-based programs.

Like all design decisions, when we're faced with a number of competing, compelling, valuable and noncompossible ideas, we've got to find a workable compromise. We don't do that except by considering all the possibilites, which is what we're doing in this case.

Why Doesn't C# Implement "Top Level" Methods?

Eric Lippert — Mon, 22 Jun 2009 18:39:00 GMT

C# requires that every method be in some class, even if it is a static method in a static class in the global namespace. Other languages allow "top level" functions. A recent stackoverflow post asks why that is.

I am asked "why doesn't C# implement feature X?" all the time. The answer is always the same: because no one ever designed, specified, implemented, tested, documented and shipped that feature. All six of those things are necessary to make a feature happen. All of them cost huge amounts of time, effort and money. Features are not cheap, and we try very hard to make sure that we are only shipping those features which give the best possible benefits to our users given our constrained time, effort and money budgets.

I understand that such a general answer probably does not address the specific question.

In this particular case, the clear user benefit was in the past not large enough to justify the complications to the language which would ensue. By restricting how different language entities nest inside each other we (1) restrict legal programs to be in a common, easily understood style, and (2) make it possible to define "identifier lookup" rules which are comprehensible, specifiable, implementable, testable and documentable.

By restricting method bodies to always be inside a struct or class, we make it easier to reason about the meaning of an unqualified identifier used in an invocation context; such a thing is always an invocable member of the current type (or a base type).

Now, JScript.NET has this feature. (And in fact, JScript.NET goes even further; you can have program statements "at the top level" too.) A reasonable question is "why is this feature good for JScript but bad for C#?"

First off, I reject the premise that the feature is "bad" for C#. The feature might well be good for C#, just not good enough compared to its costs (and to the opportunity cost of doing that feature instead of a more valuable feature.) The feature might become good enough for C# if its costs are lowered, or if the compelling benefit to customers becomes higher.

Second, the question assumes that the feature is good for JScript.NET. Why is it good for JScript.NET?

It's good for JScript.NET because JScript.NET was designed to be a "scripty" language as well as a "large-scale development" language. "JScript classic"'s original design as a scripting language requires that "a one-line program actually be one line". If your intention is to make a language that allows for rapid development of short, simple scripts by novice developers then you want to minimize the amount of "ritual incantations" that must happen in every program. In JScript you do not want to have to start with a bunch of using clauses and define a class and then put stuff in the class and have a Main routine and blah blah blah, all this ritual just to get Hello World running.

C# was designed to be a large-scale application development language geared towards pro devs from day one; it was never intended to be a scripting language. It's design therefore encourages enforcing the immediate organization of even small chunks of code into components. C# is a component-oriented language. We therefore want to encourage programming in a component-based style and discourage features that work against that style.

This is changing. "REPL" languages like F#, long popular in academia, are increasing in popularity in industry. There's a renewed interest in "scripty" application programmability via tools like Visual Studio Tools for Applications. These forces cause us to re-evaluate whether "a one line program is one line" is a sensible goal for hypothetical future versions of C#. Hitherto it has been an explicit non-goal of the language design.

(As always, whenever I discuss the hypothetical "next version of C#", keep in mind that we have not announced any next version, that it might never happen, and that it is utterly premature to think about feature sets or schedules. All speculation about future versions of unannounced products should be taken as "for entertainment purposes only" musings, not as promises about future offerings.)

We are therefore considering adding this feature to a hypothetical future version of C#, in order to better support "scripty" scenarios and REPL evaluation. When the existence of powerful new tools is predicated upon the existence of language features, that is points towards getting the language features done.

UPDATE: More thoughts on considerations motivating this potential change here.

Bug Psychology

Eric Lippert — Mon, 01 Jun 2009 16:48:00 GMT

Fixing bugs is hard.

For the purposes of this posting, I’m talking about those really “crisp” bugs -- those flaws which are entirely due to a failure on the developer’s part to correctly implement some mechanistic calculation or ensure some postcondition is met. I’m not talking about oops, we just found out that the product name sounds like a rude word in Urdu, or the specification wasn’t quite right so we changed it or the code wasn’t adequately robust in the face of a buggy caller. I mean those bugs where you were asked to compute some value and you just plain get the result wrong for some valid inputs.

Let me give you an example.

The first bug I ever fixed at Microsoft as a full-time employee was one of those. To understand the context of the bug, start by reading this post from the early days of FAIC, and then come back.

Welcome back, I hope you enjoyed that little trip down memory lane as much as I did.

Now that you understand how a VT_DATE is stored, that explains this bizarre behaviour in VBScript:

print DateDiff("h", #12/31/1899 18:00#, #12/30/1899 6:00#) / 24
print DateDiff("h", #12/31/1899 18:00#, #12/29/1899 6:00#) / 24

This prints –1.5 and –2.5, as you’d expect. There’s a day and a half between 6 AM December 30th and 6 PM December 31st, and two and a half days between the other two dates. This is perfectly understandable. But if you just subtract the dates:

print #12/31/1899 18:00# - #12/30/1899 6:00#
print #12/31/1899 18:00# - #12/29/1899 6:00#

You get 1.5 and 3, not 1.5 and 2.5. Because of the bizarre date format that VT_DATE chooses, when you convert dates to numbers, you cannot safely subtract them if they straddle the magic zero date. That’s why you need the helpful “DateDiff”, “DateAdd” and so on, methods.

The bug I was assigned was that testing had discovered a particular pair of dates which DateDiff was not subtracting correctly. I took a look at the source code for one of the helper methods that DateDiff used to do one of the computations it needed along the way. To my fresh-out-of-college eyes it looked something like this:

if (frob(x) > 0 && blarg(y)) return x – y;
else if (frob(x) < blarg(y) && blah_blah(x) > 0 || blah_de_blah_blah_blah(x,y)) return frob(x) – x + y + 1;
else if…

There were seven such cases.

My urge was to dive right in and add an eighth special case that fixed the bug. But my ability to get it right in the face of all this complexity concerned me. It seemed like this was an awfully complicated function already for what it was trying to do.

I researched the history of the code a bit and discovered that in fact variations on this bug had been entered… seven times. Each special case in the code corresponded to a particular bug that had been “fixed”, a term I use guardedly in this case. A great many of those “fixes” had actually introduced new bugs, regressing existing correct behaviour, which then in turn were “fixed” by adding special cases on top of the broken special cases that had been added to “fix” previous bugs.

I decided that this coding horror would end here. I deleted all the code (all seven lines of it! I was bold!) and started over.

Deep breath.

Spec the code requirements first. Then design the code to meet the spec. Then write the code to the design.

Spec:

* Input: two doubles representing dates in VT_DATE format.
* VT_DATE format: signed integer portion of double is number of days since 12/30/1899, unsigned fractional part is portion of day gone by.
* For example: –1.75 = 12/29/1899, 6 PM.
* Output: double containing number of days, possibly fractional, between two dates. Differences due to daylight savings time, and so on, to be ignored.

Design strategy:

* Problem: Some doubles cannot simply be subtracted because negative dates are not absolute offsets from epoch time
* Therefore, convert all dates to a more sensible date format which can be simply subtracted.

Code:

double DateDiffHelper(double vtdate1, double vtdate2)
{
return SensibleDate(vtdate2) – SensibleDate(vtdate1);
}
double SensibleDate(double vtdate)
{
// negative dates like –2.75 mean “go back two days, then forward .75 days”:
// Transform that into –1.25, meaning “go back 1.25 days”.
return DatePart(vtdate) + TimePart(vtdate);
}

I already had helper methods DatePart and TimePart, so I was done. The new code was shorter, far more readable, generated smaller, faster machine code and most important, was clearly correct. No special cases; no bugs.

It’s not that my coworkers were dummies. Far from it. These were smart people. But computer geek psychology is such that it is very easy to narrow-focus on the immediately wrong thing, and try to tweak it until it does the right thing.

When faced with these sorts of “crisp” bugs, I try to restrain myself from diving right in. Rather, I try to psychoanalyze the person – who is, of course, usually my past self – who caused the bug. I ask myself “how was the person who wrote the buggy code fooled into thinking it was correct?” Did they not have a clear specification of what the method was supposed to do? Was it misleading? Did they have a clear plan for how to proceed? If so, where did it go wrong?

If there never was either a spec or a plan, then for all you know the whole thing might only be working by sheer accident. There could be any number of design flaws in the thing that just haven’t come to light yet. Editing such a beast means adding unknown to unknown. which seldom leads to good results. Sometimes coming up with a new spec, a new plan and scrapping an existing bug farm is the best way to proceed.

For many years after that, I would ask how to implement DateDiffHelper as my technical question for fresh-out-of-college candidates that I was interviewing for the scripting dev team. I reasoned that if that was the sort of problem I was given on my first day in the office, then maybe that would be a reasonable question to ask a candidate.

When you ask the same question over and over again, you really get to see the massive difference in aptitude between candidates. I had some candidates who just picked up a marker, wrote a solution straight out on the board, wrote down the test cases they’d use to verify it, mentally ran a few of the tests in their head, and then we’d have another half hour to chat about the weather. And I had some candidates who tried earnestly to write the version using special cases, despite my specifically telling them “you might consider transforming this bad format into something more pleasant to work with”, after they got stuck on the third special case. I’d point out a bug and immediately they’d write down code for another special case, rather than stopping to think about the fact that they’d just written buggy code three times already and told me it was correct three times.

A Book By Any Other Name Would Smell As Sweet

Eric Lippert — Thu, 02 Apr 2009 16:09:00 GMT

As you might have gathered from my previous posts on the subject, I occasionally edit technical books as a hobby. It’s nice having a hobby that pays money instead of costing money. And I always learn something from every book.

Many years ago, on one of my first editing gigs, the editor asked me my opinion on what the book’s title should be. At the time I had no particularly coherent thoughts about how to title a book, but I’m almost always willing to offer an opinion on things I know little about. So I thought about it for a few minutes and responded that since the book was about how to manage enterprise IT systems by writing scripts that use the Windows Script Host, that the title should be “Managing Enterprise Systems With The Windows Script Host”. After some back-and-forth discussion between me, the editor and the author, we actually settled on that title, amazingly enough.

This is not a very good title for what is really a quite good book. I realize this now, with the hindsight of a lot more experience in thinking about how to name things.

Were I asked to criticize this title now, with that hindsight, I’d ask myself some pointed questions:

Q: Is “managing” what the target customer of the book describes themselves as doing?

A: Maybe sometimes, but we can do better. The target audience typically describes themselves as “systems administrators”, not “managers”. Cut “managing” and replace it with “Administering”.

Q: What function does the word “Enterprise” serve?

A: It discourages home-computer users from buying the book. Which is good, because they are not our target audience. But “Managing” or “Administering” already does that. It also discourages small- or medium-business sys admins from buying the book and they are in the target audience. Cut “Enterprise”.

Q: Do we really need to call out that the things being administered/managed are “Systems”?

A: No, obviously that goes without saying. Cut “Systems”.

Q: Then what noun is the object of the verb “Administering”?

A: We need to tell the potential reader that this is a book about administering Windows. The noun “Windows” must be in the title somewhere. Admins of other operating systems are explicitly not in our target audience and we must discourage them from buying this book. We look disingenuous if we don’t do that.

Q: What does “With Windows Script Host” communicate to the potential buyer?

A: It logically ties the book to a particular tool used to solve the customer’s problems. It puts the emphasis on the solution mechanism rather than on the customer’s problem.

Q: If the customer needs a circular hole in a wall, do they care much about who manufactured the drill and the drill bit?

A: No. Though there are better and worse drills, good enough is good enough. As long as the drill works reasonably well, they mostly care about the result.

The implementation details of the solution are not particularly important to the customer, even if they’re the person doing the implementation. What’s important to the customer is the benefit obtained by taking the advice in the book.

Q: What is the compelling overall benefit to the customer of using the advice in the book?

A: They can write scripts to automate tasks, putting in some up-front time to write the script and accruing the benefit of having a previously time-consuming and irksome administration task performed quickly and automatically by the script host.

Whew. That was a lot of pointed questions.

I wasn’t there for this conversation, but I imagine that the editors and author went through a similar mental process when they prepared the second edition for publication. The second edition has a far better name: Automating Windows Administration. It contains keywords “Windows” and “Administration” which attract the target audience – professional administrators of Windows-based systems – and repels people not in the target audience. And it leads with the compelling benefit to the customer: automation. “Automation” makes work easier. Leading with “Managing” puts the emphasis on the hard part of the job, not on making it easier. And the new name doesn’t tie the book or the reader to committing to a particular toolset.

Good naming is a hugely important aspect of design; the name of a thing is almost always how the thing first enters the consciousness of a potential consumer. Next time, we’ll explore some more aspects of what makes a name “good” or “bad” for a particular purpose.

Human sacrifice, dogs and cats living together, mass hysteria! and thread model errors!

Eric Lippert — Tue, 08 May 2007 02:22:00 GMT

Reader Shaka comments on my post about error messages that "catastrophic failure" really does take the cake as being a terrible error message.

I fondly remember the first time I saw "catastrophic failure" as an error message. I was an intern, running the build lab for Visual Basic for Applications, and I was trying to get the PowerPC cross-compiler working so that we could build PPC binaries on x86 hardware. (Note that this was in the early 1990's. The VS build lab is now an entire team of people who have dedicated circuits just for the cooling equipment for all their computers. We've come a long way from an intern, a closet, and six machines named after opponents of Godzilla (*).)

Anyway, the compiler had a bug which caused it to run out of stack while compiling a particular module and the error was "catastrophic failure". This amused me to no end at the time. I laughed out loud, literally. I mean, fatal, sure. That process is going down. But "catastrophic"? I expect catastrophes to at least result in my hard disk becoming unreadable. I want bridges collapsing and floods and mass hysteria!

I have therefore always been rather embarrassed that the error message you get when you call the script engine on the wrong thread is "catastrophic failure". That, unfortunately, is the somewhat breathless and overstated string associated with E_UNEXPECTED. Basically we want to say "you called us in a completely unexpected way which thoroughly violates the engine contract, please don't do that". But "catastrophic failure" is what you get. I wish now that we'd declared a new HRESULT just for "you've violated the engine contract". But it's far, far too late now.

(*) In the interests of total accuracy: the OLE Automation build machines were named after Godzilla's opponents: Mothra, Monster Zero, etc. The VBA build machines were named after species of marine mammals: sei, humpback, etc.

Checking For Script Syntax Errors, This Time With Code

Eric Lippert — Wed, 12 Oct 2005 19:37:00 GMT

A number of people asked me to clarify yesterday's entry. Rather than try to talk you through it, I think the code is straightforward enough to speak for itself. Here's a little skeleton that I just whipped up.

#include <stdio.h>
#include <activscp.h>
#include <new>

const GUID CLSID_VBScript = {0xb54f3741, 0x5b07, 0x11cf, {0xa4, 0xb0, 0x00, 0xaa, 0x00, 0x4a, 0x55, 0xe8}};
const GUID CLSID_JScript = {0xf414c260, 0x6ac0, 0x11cf, {0xb6, 0xd1, 0x00, 0xaa, 0x00, 0xbb, 0xbb, 0x58}};

class MySite : public IActiveScriptSite {
private:

ULONG m_cref;
virtual ~MySite() {}

public:

  MySite() {
   this->m_cref = 1;
  }

STDMETHOD_(ULONG, AddRef)() {
return ++this->m_cref;
}

STDMETHOD_(ULONG,Release)() {
    --this->m_cref;
  if (this->m_cref == 0) {
     delete this;
      return 0;
  }
    return this->m_cref;
  }

  STDMETHOD(QueryInterface)(REFIID iid, void ** ppv) {
   if (ppv == NULL)
      return E_POINTER;
    if (IsEqualIID(iid, IID_IUnknown))
      *ppv = (IUnknown*)this;
    else if (IsEqualIID(iid, IID_IActiveScriptSite))
   *ppv = (IActiveScriptSite*)this;
    else {
      *ppv = NULL;
      return E_NOINTERFACE;
    }
    this->AddRef();
    return S_OK;
}

STDMETHOD(GetLCID)(LCID * plcid) {
return E_NOTIMPL;
}

  STDMETHOD(GetItemInfo)(
  LPCOLESTR pstrName,
   DWORD dwReturnMask,
    IUnknown ** ppunkItem,
    ITypeInfo ** ppti) {
    return E_NOTIMPL;
  }

STDMETHOD(GetDocVersionString)(BSTR * pbstrVersion) {
return E_NOTIMPL;
}

STDMETHOD(OnScriptTerminate)(
   const VARIANT * pvarResult,
   const EXCEPINFO * pexcepinfo) {
    return S_OK;
  }

STDMETHOD(OnStateChange)(SCRIPTSTATE state) {
return S_OK;
}

  STDMETHOD(OnEnterScript)() {
   return S_OK;
}

STDMETHOD(OnLeaveScript)() {
    return S_OK;
  }

STDMETHOD(OnScriptError)(IActiveScriptError * perror) {
    EXCEPINFO excepinfo;
    LONG column = 0;
    ULONG line = 0;
    DWORD context = 0;
    BSTR bstrLine = NULL;
    memset(&excepinfo, 0x00, sizeof excepinfo);
   perror->GetExceptionInfo(&excepinfo);
    if (excepinfo.pfnDeferredFillIn != NULL)
     excepinfo.pfnDeferredFillIn(&excepinfo);
    perror->GetSourceLineText(&bstrLine);
   perror->GetSourcePosition(&context, &line, &column);

   wprintf(L"Error on line %ld column %ld\n", line, column);
   if (bstrLine != NULL)
      wprintf(L"Line: %s\n", bstrLine);
    if (excepinfo.bstrDescription != NULL)
     wprintf(L"Description: %s\n", excepinfo.bstrDescription);
    if (excepinfo.bstrSource != NULL)
     wprintf(L"Source: %s\n", excepinfo.bstrSource);
    if (excepinfo.bstrHelpFile != NULL)
     wprintf(L"Help: %s\n", excepinfo.bstrHelpFile);

    SysFreeString(bstrLine);
    SysFreeString(excepinfo.bstrDescription);
    SysFreeString(excepinfo.bstrSource);
    SysFreeString(excepinfo.bstrHelpFile);

return S_OK;
}
};

void main() {
HRESULT hr = S_OK;
HRESULT hrInit;
IClassFactory * pfactory = NULL;
IActiveScript * pscript = NULL;
IActiveScriptParse * pparse = NULL;
IActiveScriptSite * psite = NULL;

hr = hrInit = OleInitialize(NULL);
if (FAILED(hr))
goto LError;

hr = CoGetClassObject(CLSID_VBScript, CLSCTX_SERVER, NULL,
IID_IClassFactory, (void**)&pfactory);
if (FAILED(hr))
goto LError;

hr = pfactory->CreateInstance(NULL, IID_IActiveScript, (void**)&pscript);
if (FAILED(hr))
goto LError;

psite = new(std::nothrow) MySite();
if (psite == NULL) {
hr = E_OUTOFMEMORY;
goto LError;
}

hr = pscript->SetScriptSite(psite);
if (FAILED(hr))
goto LError;

hr = pscript->QueryInterface(IID_IActiveScriptParse, (void**)&pparse);
if (FAILED(hr))
goto LError;

hr = pparse->ParseScriptText(L"Function Foo \n Foo = 123 \n End Funtcion \n",
NULL, NULL, NULL, 0, 1, 0, NULL, NULL);

if (FAILED(hr))
goto LError;

LError:

if (FAILED(hr))
printf("%0x\n", hr);

if (pparse != NULL)
pparse->Release();

if (psite != NULL)
psite->Release();

if (pscript != NULL) {
    pscript->Close();
   pscript->Release();
  }

if (pfactory != NULL)
pfactory->Release();

if (SUCCEEDED(hrInit))
OleUninitialize();
}

As you would expect, this program prints out the information about the error, and ParseScriptText returns SCRIPT_E_REPORTED to indicate that there was an error but it has already been reported. Had there been no error, the script would not have actually run; the engine is not started, just initialized.

Error on line 3 column 5
Line: End Funtcion
Description: Expected 'Function'
Source: Microsoft VBScript compilation error
80020101

Checking For Script Syntax Errors

Eric Lippert — Tue, 11 Oct 2005 20:35:00 GMT

A reader asked me recently whether there was a way to check a chunk of JScript or VBScript for syntax errors without actually running the code. I'm sure that there are many third-party tools which you could find that do this. If you have your own script host, you can do it yourself quite easily.

The trick is to initialize the engine by setting the script site, but do not do anything that would move the engine from initialized into started state. (Note that attempting to evaluate an expression moves the engine to started state.)

If the engine is initialzed but not started then calling ParseScriptText will check the text passed in for syntax errors but will not run the script. Rather, if the script compiles successfully, it is simply marked as "needs to run when the engine is started".

Unfortunately the script engines do not have an error-recovering parser, so they will detect only the first syntax error and then bail out. Still, better than nothing.

Local variables considered not very harmful

Eric Lippert — Tue, 04 Oct 2005 20:22:00 GMT

Like I said, that code from last time was just test code, not real production code. Though clearly it works, I'd never write code like that in a million years. I'm not thrilled with the way it uses the answer variable of the outer scope as an accumulator, and it is profoundly weird that the "do this function n times" function is a member of the Number prototype and not the Function prototype. Worse still, we have a function that is essentially used as a composition operator that only makes sense to use on functions that have side effects and no arguments or returns. That's a kind of crazy way to do composition operations.

I'd probably do something more like this:

First, define a self-composition factory on the Function prototype, so that it is of general use on all functions of one argument, not just functions of no arguments and no returns that have side effects. What we'll do is make a new member function for every function object that returns a new function which is equivalent to calling the input function n times:

Function.prototype.times = function(n) {
var f = this;
return function (x) {
    while (n > 0) {
      x = f(x);
      --n;
    }
    return x;
};
}

Obviously we don't need to compose functions of more than one argument because we want to feed the single output back into the input. Now we compose the function "multiply something by x" with itself n times. That gives us the function "multiply something by x, n times". Pass 1 to that function and we have a handy raiseTo function:

Number.prototype.raiseTo = function(power) {
var x = this;
return function(y) {
return x * y
}.times(power)(1);
}

No fuss, no muss, no accumulators, no side effects, no non-number-related functions on the number prototype. I like it!

Heck, if we wanted to get really crazy then we could eliminate the local variables entirely by introducing another function constructor in-line:

Function.prototype.times = function(n) {
return function(f) {
    return function (x) {
      while (n > 0) {
        x = f(x);
        --n;
      }
      return x;
    }
}(this);
}

Number.prototype.raiseTo = function(power) {
return function(x) {
   return function(y) {
      return x * y
    }
}(this).times(power)(1);
}

Local variables are actually an unnecessary syntactic sugar in Jscript. We can do everything that local variables do by cleverly nesting function scopes. However, it becomes somewhat less easy to read, so I would stick to using local variables if I were you!

Guru meditations on scope chains of closures

Eric Lippert — Fri, 30 Sep 2005 22:41:00 GMT

I just had a really interesting meeting with some of the scripting community MVPs. I may write up some notes on that meeting here next week, so watch this space.

In other news, someone asked me last night (and I quote)

Oh ECMA guru, can you provide a succinct explanation of why the following code works, but if I replace x with this it fails?

Number.prototype.times = function(f) {
for(var i = 0; i < this; i++)
f();
}
Number.prototype.raiseTo = function(n) {
var answer = 1;
var x = this;
n.times(function(){ answer = x * answer;}); // succeeds
//n.times(function(){ answer = this * answer;}); // fails!
return answer;
}
(3).raiseTo(2).raiseTo(5);

Well I'd hardly describe myself as a guru, but I take the questioner's point -- surely if you set x to this then x and this should be aliases for each other, right?

Often. But not in this case.

The inner function's execution context contains a scope chain that includes the variable object of the outer function, so the inner function can see x by looking up the scope chain. But this is not a variable, so it is not member of the outer function's variable object. Rather, it is a member of the outer function's execution context.

Therefore the inner function's execution context gets the global this, in accordance with the ECMAScript specification, revision 3, section 10.2.3:

The caller provides the this value. If the this value provided by the caller is not an object (including the case where it is null), then the this value is the global object.

The global object is not something that can be multiplied, so the alternate version of the program fails.

The code above was of course not real production code, it was just code that came up while testing an engine implementation. Obviously JScript already has a built-in power function that works much better than this crazy thing. But I'm in an expansive mood, so next time I'll talk a bit about some of the shortcomings of this programming style, and some ideas for improving it.

Implementing Event Handling, Part Two

Eric Lippert — Wed, 21 Sep 2005 21:51:00 GMT

It's been an insanely busy month for me, between having multiple out-of-town guests, throwing a party for the people who couldn't make it to the wedding, and oh yeah, getting up to speed on the C# compiler and trying to understand the implications that LINQ features are going to have on the current implementation. Not much time for blogging. Hopefully October will be a little bit more under control.

Anyway, I was talking about early-bound event binding. Basically the idea is that the source and the sink agree upon an interface that the source can call on the sink whenever the source wishes to fire an event. Before we get into that more, I want to talk briefly about early- and late-bound code.

At an implementation level, what is the difference between early- and late- bound code? In the early-bound world, a particular function on an interface gets called when the caller dereferences the callee's virtual function table and transfers control directly to the function by changing the instruction pointer on the chip. In the late-bound world, the caller calls IDispatch::Invoke and passes in a magic number that tells the callee what function it should be calling, and the callee is then responsible for dispatching the function appropriately. (Hence the name "IDispatch".)

The script engines use IDispatch all the time to call out to functions on objects. When calling an object late-bound, you don't know until you actually try the call whether or not it is going to succeed, because you do not know the interface the object implements. So you call GetIdsOfNames to get the magic number associated with a particular function, Invoke on that magic number, and let the callee sort it out. In this situation, the caller (the script engine) knows the name of the function it wants to call, and the callee (the object) can map the name to the appropriate identifier.

Now consider how this works if IDispatch is the interface over which the source (the object) is calling back the sink (the script host). This appears to be the same situation, but in fact it is completely different. It appears the same because from the perspective of how COM actually manages all the calls, its exactly the same. IDispatch is an interface like any other, and the source can call the sink's IDispatch to its heart's content if that's the interface that they agree to talk over.

But look at it from the point of view of the sink: the caller knows what the magic number means and the callee does not, but it's the callee who is being asked to do the dispatching! You're sitting there sinking events of who knows what object, and every now and then you get a call on IDispatch::Invoke with some unknown dispid. What the heck are you supposed to do with that? In the late-bound world, instead of getting a nice direct call on "Tick()... Tick()... Tick()..." you're getting "12... 12... 12..." and you have no idea what "12" means.

Let's tie this in to scripting. Suppose you're in Windows Script Host and you do something like:

Sub Timer_Tick()
'whatever
End Sub
Set Timer = CreateObject("mytimer")
WScript.ConnectObject Timer, "Timer_"
Timer.Start 10
WScript.Sleep 1000

There are many IDispatch objects here and we'll look at three of them. First, there's the source, that is, the timer object. Then there's the sink, owned by the host and created when the source is connected to it. Finally there is the script engine itself, upon which the host can dispatch calls to global functions such as the event handler.

ConnectObject is given a source object. It has no idea what early-bound outgoing interface is on that object, and it certainly doesn't have an implementation of such an interface even if there is one, so it is going to have to do a late bound sink. It creates an object to act as the sink, gets an IDispatch-enabled connection point from the source, and advises it.

Now the script engine calls Start (via IDispatch on the source) and goes to sleep.

Pretty soon the timer invokes the sink, passing in the dispatch identifier for Tick.

The sink needs to know which sub to call in the script engine.

Fortunately, it has an IDispatch pointer to the source, and a dispatch identifier.

Unfortunately, though IDispatch provides a function which maps from name to id, it provides no function that maps the other way.

Fortunately, IDispatch does provide a function that enables the host to obtain a type information structure which contains a list of all the methods and what their dispatch identifiers are. Therefore we can search all the methods in the type info and check to see which has the desired dispatch identifier. That then gives us the method name, so we know which event handler function to dispatch on the script engine.

Unfortunately there is a major design flaw in IDispatch -- it gives you the type info for the incoming interface -- the ITimer. But there is no way to take the ITypeInfo for ITimer and say "give me the type info for the class as a whole so that I can obtain the type info for the outgoing interface".

Fortunately, IProvideClassInfo was invented. IPCI gives you back the "root" type info for an object, from which you can obtain a type info for the default outgoing interface, from which you can map the dispatch identifier to the name.

Unfortunately, many objects do not implement IProvideClassInfo, and therefore cannot have their events hooked up by ConnectObject.

(I feel a little bit like the ending of Dr. Strangelove here. Fortunately, they stop General Ripper in time. Unfortunately, the secret code died with him. Fortunately they figure out the code. Unfortunately, the radio is broken. Fortunately, the bomb bay doors are stuck. Unfortunately, they fix them, and the Doomsday Device destroys the world. Bummer.)

The moral of this story is simple: for late bound events to work, at some point the class of the source must be known. And therefore:

"automagic event binding" in IE only works on "named items" present in the script engine. (The script engines require that the host provide a coclass type info for named items, and build the sinks very early on, before other code runs.)
WScript.CreateObject can always hook up events. The class type info is known because CreateObject had to create an instance of the class.
WScript.ConnectObject can hook up events only if the object implements IProvideClassInfo

I hope that clears up any confusion about what IProvideClassInfo is for!

Implementing Event Handling, Part One

Eric Lippert — Sat, 10 Sep 2005 01:35:00 GMT

Back in February I posted a bit about how script hosts such as Windows Script Host dynamically hook up event sources (objects) to event sinks (chunks of script that run when the event fires.) It has become apparent from some questions I've received recently that it would be helpful to have a more detailed explanation of how event handling works in COM, and how that applies to late-bound scripting languages.

We'll start in the early-bound world and then move into the scripting world next week.

Suppose you've got an object Timer that has methods Start and Stop, and event Tick. The methods are straightforward. We define an interface that has these methods on it:

interface ITimer : public IUnknown
{
public:
virtual void Start(int interval) = NULL;
virtual void Stop() = NULL;
}

When users want to call those methods, they just get a pointer to the IUnknown of the object, QueryInterface it for ITimer, and then call the appropriate method on the virtual function table.

But the user doesn't just want to call the timer. Not much point in that! They want the timer to inform some other piece of code whenever a tick event occurs. Somehow the sink - the listener function - is going to have to be called. This means that the timer code has to be running and it has to call some arbitrary code that it knows nothing about.

How the timer code manages to run itself is a topic for another day; today we'll just worry about getting the call from the source to the sink. The sink is going to have to somehow register itself with the source, and they'll negotiate what interface the source will call on the sink when the event occurs. In this case the sink wants to know when a tick happens, so the sink should implement something like

interface ITick : public IUnknown
{
public:
virtual void Tick(ITimer * pSource) = NULL;
}

OK, so suppose we have a source that implements ITimer and a sink that implements ITick. Somehow they have to get hooked up. (Error checking removed.)

pSource->QueryInterface(IID_IConnectionPointContainer, &pContainer);
pContainer->FindConnectionPoint(IID_ITick, &pConnection);
pConnection->Advise(pSink, &cookie);

The sink says to the source "do you contain connection points that can call me back on ITick?" The source says "sure, here's an object that you can register yourself with that will call you back". The sink then says "Super, here's a pointer back to me, and please give me a 'cookie' number that I can use to uniquely identify this relationship so that I can shut it down later."

The source now has a pointer to the sink, so when a tick event occurs, the source can call the sink.

Next time we'll explore what happens in the scripting world where the sink only speaks IDispatch.

250% of what, exactly?

Eric Lippert — Thu, 01 Sep 2005 20:13:00 GMT

I just got a question this morning about how to take two collections of items and determine how many of those items had the same name. The user had written this straightforward but extremely slow VBScript algorithm:

For Each Frog In Frogs
For Each Toad In Toads
    If Frog.Name = Toad.Name Then
      SameName = SameName + 1
      Exit For
    End If
Next
Next

There were about 5000 frogs, 3000 toads and 1500 of them had the same name. Every one of the 3500 unsuccessful searches checked all 3000 toads, and the 1500 successful searches on average checked 1500 toads each. Each time through the inner loop does one loop iteration, two calls to the Name property, one string comparison. Add all those up and you get roughly 50 million function calls to determine this count.

This code has been somewhat simplified – the actual user code was doing more work inside the loop, including calls to WMI objects. The whole thing was taking 10+ minutes, which is actually pretty fast considering how much work was being done. Each individual function call was only taking a few microseconds, but fifty million calls adds up!

Now, we've been down this road before in this blog (here, here and here) and so of course I recommended building a faster lookup table rather than doing a full search through the collection every time.

Set FrogLookup = CreateObject("Scripting.Dictionary")
For Each Frog In Frogs
FrogLookup(Frog.Name) = Frog
Next
For Each Toad In Toads
If FrogLookup.Exists(Toad.Name) Then SameName = SameName + 1
Next

Which is much, much faster. That's only about 16 thousand function calls. Now, this is maybe not an apples-to-apples comparison of function calls, but we at least have good reason to believe that this is going to be several times faster.

And indeed it was. But I'm still not sure how much, which brings me to the actual subject of today's blog. The user reported that the new algorithm was "250% better". I hear results like this all the time, and I always have to ask to clarify what it means. You can't just say "n% better" without somehow also communicating what you're measuring.

(UPDATE: This reported result understandably confused some readers. Clearly the new loop here is thousands of times faster, not a mere 250% faster. As I said before, the sketch above is highly simplified code. The real-world code included many thousands of additional calls to WMI objects which were not eliminated by this optimization. Eliminating these 50 million function calls helped -- you should always eliminate the slowest thing first! But doing so also exposed a new "hot spot" that needed further optimization. However, the point of this article is not the benefits of using lookup tables, but rather that using unexplained percentages to report performance results is potentially misleading. The result above is merely illustrative. See the comments for more details.)

Allow me to illustrate. Suppose I have a web server that is serving up ten thousand pages every ten seconds. I make a performance improvement to the page generator so that it is now serving up fifteen thousand pages every ten seconds. I can sensibly say:

performance has improved by 50%, because we are now serving up 5000 more pages every ten seconds, and 5000 is 50% of the original 10000. In this world, any positive percentage is good.
performance is now 150% of original performance because 15000 is 150% of 10000. In this world, 0%-100% worse or the same, 100%+ is good.
We've gone from 1000 microseconds per page to 667 microseconds per page, saving 333 microseconds per page. 333 is 33% of 1000, so we've got a 33% performance improvement. In this world, 0% is bad, 100% is perfect, more than 100% is nonsensical.

If I can sensibly say that performance is better by 50%, 150% and 33%, all referring to exactly the same improvement, then I cannot actually be communicating any fact to my listeners! They need to know whether I'm measuring speed or time, and if speed, whether I'm comparing original speed to new speed or original speed to the difference.

So what is "250%" better? Clearly not raw timings. If this loop took 10 minutes to run before, 250% of 10 minutes is 25 minutes, but surely it is not running in -15 minutes now! I assume that the measurement is speed -- say, number of loops runnable per hour. If before it took ten minutes and therefore we could run this loop six times per hour, and now it is 250% better, 250% of 6 is 15, and this is "better", so we need to add. So that's 21 loops per hour, or about 3 minutes per loop. Had the user accidentally said "250% faster" but meant to say "250% of previous performance" then we'd conclude that 250% of 6 per hour is 15 per hour, so now we've got 4 minutes per loop.

And of course, this is assuming that the person reporting the improvement is actually trying to communicate facts to the audience. Be wary! Since 33%, 50% and 150% are all sensible ways to report this improvement, which do you think someone who wants to impress you is going to choose? There are opportunities here for what Kee Dewdney calls "percentage pumping" and other shyster tricks for making weak numbers look more impressive. Professor Dewdney's book on the subject, "200% of Nothing", is quite entertaining.

The moral of the story is: please do not report performance improvements in percentages. Report performance improvements in terms of raw numbers with units attached, such as "microseconds per call, before and after change", or "pages per second, before and after change". That gives the reader enough information to actually understand the result.

(And the other moral is, of course, lookup tables are your friends.)

VBScript Default Property Semantics

Eric Lippert — Tue, 30 Aug 2005 20:15:00 GMT

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. Why does reading work but writing fail? This works in VB6, why not VBScript?

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 foo = bar typed as variants it cannot tell whether this means "set the default property of foo to bar" or "set foo to bar". The VB compiler chooses the latter every time. VBScript is a weakly typed subset of VB -- in VBScript, everything is a variant. So in VBScript, all assignments are treated as though the value is actually being assigned to the variable, not the default property. Therefore this is by design - this is for compatibility with VB6's behaviour. Had we written the same program in weakly-typed VB6, we'd get the same result.

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 blah is an object with a property fred that is an object, and fred has a default property which is a string. If you say foo = blah.fred then foo is assigned the default value of fred even though we lack the compile-time type information. foo isn't set to the object fred. Of course, in this case we know to fetch the default property at runtime because we know the runtime type of fred and also know that there is no Set keyword. These two facts are sufficient to cause the runtime engine to always fetch the default property.

Or suppose you have an object Baz with a property Table, Table has a default parameterized property Item which returns an object that has a string property Blah: Then this works just fine:

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 Baz.Table.Item(1).Blah. The script engine has every reason to believe that Table is a function or parameterized property of Baz. This problem is solved by pushing it off to the implementation! The rule for implementers of IDispatch::Invoke is if all of the following are true:

the caller invokes a property
the caller passes an argument list
the property does not actually take an argument list
that property returns an object
that object has a default property
that default property takes an argument list

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 IDispatch::Invoke. It also leads to some mind-numbingly complex code in the VBScript IntelliSense engine that Visual Studio uses. Making default property IntelliSense work with such a dynamically typed language was a piece of work, lemme tell ya. As I mentioned earlier, there are in fact some odd corner cases that are slightly different between VB6 and VBScript IntelliSense. I also talked a bit about left-hand-side default property semantics earlier.