Fabulous Adventures In Coding : JScript .NET

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.

C# 3.0 is still statically typed, honest!

Eric Lippert — Tue, 27 Sep 2005 20:03:00 GMT

Since LINQ was announced I've seen a lot of really positive feedback and a lot of questions and concerns. Keep 'em coming! We need this feedback so that we can both correct misconceptions early and get the design right now.

One of the misconceptions that I've seen a lot over the last few days in forums, blog posts and private emails is a confusion about what the new "type inferencing" feature implies for the type safety of the language. Apparently we have not been sufficiently clear on this point: C# 3.0 will be statically typed, just like C# 1.0 and 2.0. The var declaration style does not introduce dynamic typing or duck typing to C#.

I think the confusion may arise from familiarity with other languages such as JScript. In JScript this is perfectly legal:

var foo = new Blah();
foo = 123;
foo = "hello";

JScript is a dynamically typed language. You can assign any value of any type to a var.

In C# 3.0, the var statement means "look at the type of the thing assigned to the variable, and act as though the variable was declared with that type." In other words, in C# the code above is just a syntactic sugar for

Blah foo = new Blah();
foo = 123;
foo = "hello";

which of course would produce a type error on the second and third lines.

If you take a look at section 26.1 of the C# 3.0 specification you'll see that the var statement has a lot of restrictions on it to ensure that the compiler always has enough information to make the correct type inference. Namely:

the declarator must include an initializer, so that we can infer the type of the variable from the type of the initializer
the initializer has to be something that we can figure out the type of – not null or a collection initializer

Compare this to JScript .NET, which has a much stronger type inference mechanism. JScript .NET does not require initializers in var statements; the compiler tracks all assignments to the variable and infers the best type. If, say, only strings are assigned to a variable then it will infer the string type. JScript .NET also infers return types of functions by a similar mechanism. But the goal of the JScript .NET type inference mechanism was to increase the performance of legacy dynamically typed code. If we can infer a type and thereby generate faster, smaller code, we do so. If not, we don't.

Then why introduce this syntactic sugar in C# 3.0? C# doesn't have a body of legacy dynamic code like JScript and already generates efficient code.

There are two reasons, one which exists today, one which will crop up in 3.0.

The first reason is that this code is incredibly ugly because of all the redundancy:

Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();

And that's a simple example – I've written worse. Any time you're forced to type exactly the same thing twice, that's a redundancy that we can remove. Much nicer to write

var mylists = new Dictionary<string, List<int>>();

and let the compiler figure out what the type is based on the assignment.

Second, C# 3.0 introduces anonymous types. Since anonymous types by definition have no names, you need to be able to infer the type of the variable from the initializing expression if its type is anonymous.

We'll discuss the reasoning behind anonymous types in another post.

Instance-bound nested classes in JScript .NET

Eric Lippert — Mon, 02 May 2005 21:30:00 GMT

The other day someone asked me about a slightly odd but very useful feature in JScript.NET, and I figure if one person asks me about it, maybe more people want to know as well.

In JScript.NET you can say

class alpha {
var foo;
class bravo {
    function blah() {
      print (foo);
    }
}
}

var x = new alpha();
x.foo = 123;
var z = new x.bravo();
z.blah();

the instance of alpha is bound to the instance of bravo's scope chain. Therefore when z.blah runs, foo is bound to x.foo. Of course, this means that when you instantiate a new instance of the inner class, you've got to do so via an instance of the enclosing class.

We implemented this in JScript .NET so that ASP.NET would work nicely. Behind the scenes, ASP.NET builds a class which extends a page class and sticks your code into it. If you had something like

Then that would generate a class roughly like this:

class MyPage extends Page {
class foo {
     function bar() {
       Response.Write("hello");
     }
}
function Render() {
    var x = new foo();
    foo.bar();
}
}

The nested class is bound to the page instance, and hence can access the Response object of the page base class. The JScript.NET compiler is smart enough to figure out that really you meant

var x = new this.foo();

C# does not implement instance-bound nested classes. If you want C#-like behaviour in JScript.NET, you can get it. In JScript.NET if you don't want a nested class to be bound to an instance of the outer class then you stick the static modifier onto the inner class declaration. In that case, the enclosing class essentially becomes not much more than another level of namespace.

Would you like to see something like this in a hypothetical future version of C#? Would it be useful?

Fun With Floating Point Arithmetic, Part Six

Eric Lippert — Wed, 26 Jan 2005 21:02:00 GMT

One more thing -- I said earlier that the VBScript float-to-string algorithm was a little bit different than the JScript algorithm. We can demonstrate quite easily by comparing the outputs of two nigh-identical programs:

' VBScript
print 9.2 * 100.0 < 920.0
print 919.9999999999999 < 920.0
print 920.0000000000001 > 920.0

' JScript
print(9.2*100.00 < 920.0);
print(919.9999999999999 < 920.0);
print (920.0000000000001 > 920.0);

As you'd expect, the last two comparisons of each result in true. But why does the first also result in true? Because of the very issues we've been talking about in the last five parts -- 9.2 cannot be exactly represented as a float. There is some representation error. When the float is multiplied by 100, the representation error also gets 100 times larger, and that's big enough to make it slightly smaller than 920.

If that's the case then why do these programs produce different output?

print 9.2 * 100.0
print 919.9999999999999
print 920.0000000000001

print(9.2*100.00);
print(919.9999999999999);
print(920.0000000000001);

The VBScript program produces 920, 920, 920. The JScript program produces 919.9999999999999, 919.9999999999999, 920.0000000000001. What is up with that?

The JScript algorithm for converting floats to strings is designed to have as much precision as possible. Since 919.9999999999999 and 920.0 have different binary representations as floats, they have different string representation.

The VBScript algorithm on the other hand assumes that if you have 919.9999999999999 or 920.0000000000001, that probably what has happened is you've run into a floating point error accrual issue, and it rounds it back to the correct value for you when it displays the string.

This heuristic means that VBScript (paradoxically) loses a small amount of precision and yet displays more accurate results for typical cases. The down side is that VBScript is unable to display full precision when you really DO want to represent 919.9999999999999. Such cases are quite rare though, and the error created in such cases is tiny.

Fun with Floating Point Arithmetic, Part Five

Eric Lippert — Thu, 20 Jan 2005 18:56:00 GMT

I went to Joel Spolsky's geek dinner at Crossroads the other night, which was a lot of fun. I didn't get much of a chance to chat with Joel, as he was surrounded by a cadre of adoring fans three deep the whole time. I mostly hung out with KC and Larry and some other attendees and had an interesting talk about digital rights management, corporate blogging, and the difficulties of finding good quality Jackie Chan movies in the original Chinese.

I ran into Wesner Moise, who I first met long ago when he was working on Access or Excel or one of those Office kind of products but haven't really run into since. He was rather surprised that I remembered his name, but hey, how many Wesner Moises do you think I meet?

Anyway, coincidentally, Wesner has also been running a series on the perils of floating point and integer mathematics on his blog recently. Check it out!

*********************************

I said a while back that floating point math is nothing like the math we're used to. Consider some of the properties that define real number addition. For instance:

closure: x + y is a number
commutative: x + y = y + x
unique zero: a + b = a if and only if b = 0
associative: (x + y ) + z = x + (y + z)

and so on, and similarly for multiplication. Commutivity still holds, but many of these rules do not work in floating point arithmetic. I'll dig into a few of them here -- for more math rules that don't work in floating point, see Wesner's blog articles on the subject. He lists dozens of them!

Consider the closure property, for example. It's not true in VBScript:

print 10^308 + 10^308 ' Overflow error

It is true in JScript, if you consider Infinity to be a number.

The commutative property is true in both VBScript and JScript, but the unique zero, and hence the associative property, are true in neither: print 10^20 = 10^20 + 5000 prints True -- So clearly, zero is not a unique number which, when added, results in the same value. (Zero is unique in that it is the only number when added to EVERY number, results in no change. But almost every number has multiple values which result in no change when added.)

That means that the associative property goes out the window: print 10^20 + (5000 + 5000) = (10^20 + 5000) + 5000 prints False

The fact that the order in which you make the additions can affect the result makes a difference if you are designing algorithms that must add up lots of little things to one big thing. In those cases, you should try to add together all the little things first, and then add the total to the big thing. That way, the small additions are done with the most precision possible.

There's a related error due to rounding off. 1/100 cannot be represented perfectly accurately in binary any more than 1/3 can be represented perfectly in decimal:

var steps = 100;
var start = 10;
var stop = 11;
var current = start;
do
{
print(current);
current = current + (stop-start)/steps;
} while (current < stop)

Which ends up with

...
10.96999999999998
10.979999999999979
10.989999999999979
10.999999999999978

This actually takes 101 steps, because the last one through the loop gets to 10.999999999999978, which is less than 11.0. This tiny accumulated error results in the algorithm running for 1% too many steps. A better algorithm is to do the looping in integers and compute the current value anew every time:

var steps = 100;
var start = 10;
var current;
for (var step = 0; step < steps ; ++step)
{
current = start + step/steps;
print(current);
}

That actually runs the right number of steps.

A corollary of this is that you should almost never compare two floating point numbers for equality, because you never know when some rounding error might have crept in. Rather, subtract them and look at the absolute difference. For instance, if you know that x and y are positive floats that are likely to be close to each other, don't say if (x==y), say if (Math.abs(x-y) < 0.0001) or if (Math.abs(x-y) < 0.0000001 * x) or whatever makes sense in your application. (If you need to deal with NaNs and infinities, simple subtraction is anything but!)

We saw above that addition of a small number to a large number can lead to an erroneous result, but the error was extremely small. An error of 5000 in a number as big as 10²⁰ is 0.00000000000002%, which ain't bad. We'd expect that subtraction of two numbers very close to each other would also produce an erroneous result, but with a similar error percentage.

We'd be wrong. Here's an example:

Suppose you have to solve an arbitrary quadratic equation:

A x² + B x + C = 0

The solutions are well known, so we can write a little subroutine:

Sub SolveQuadratic(A, B, C)
Discriminant = B*B-4*A*C
If Discriminant < 0 Then
    Print "No real solutions"
Else
    Print (-B + Sqr(Discriminant)) / (2 * A)
    Print (-B - Sqr(Discriminant)) / (2 * A)
End If
End Sub
SolveQuadratic 2, 5, -12

And sure enough, it prints out -4 and 1.5, done. What about

SolveQuadratic 1, -10000000.0000001, 1

The correct solutions are 10000000 and 0.0000001, but this prints out 10000000 and 9.96515154838562E-08, yielding an error of nearly 3.5%! We've got about a hundred trillion times as much error here as we did in the addition. Why?

Because B and the root of the discriminant are very, very close to each other. You only get 15 decimal places of accuracy, and we've used them all up. Therefore, the difference is going to be very inaccurate. Their sum, however, is going to be quite accurate, since they're of similar size and precision.

Fortunately, in this example there's a trick. The product of the two solutions is always C / A, so we can use this fact to write a better algorithm:

Sub SolveQuadratic(A, B, C)
Discriminant = B*B-4*A*C
If Discriminant < 0 Then
Print "No real solutions"
Exit Sub
End If
Soln1 = (-B - Sqr(Discriminant)) / (2 * A)
Soln2 = (-B + Sqr(Discriminant)) / (2 * A)
If Abs(Soln1) < Abs(Soln2) Then Soln1 = Soln2
Soln2 = C / (A * Soln1)
Print Soln1
Print Soln2
End Sub

Which produces a much more accurate result.

But wait a minute -- addition is order-dependent, as we've seen. so are multiplication and division. Should that be ( C / A ) / Soln1 or C / (A * Soln1) ? Or does it even matter? Figuring that out is left as an exercise for the reader!

JScript .NET Type Coercion Semantics, Part Four: Coercion at last

Eric Lippert — Tue, 10 Aug 2004 17:56:00 GMT

Before I get going, a couple notable milestones.

First, this is post number 200! Who would have believed that I'd have so much to ramble on about? ("Anyone who knows you" would be the correct answer to that rhetorical question I suppose.)

Second, as of Sunday I am now over (cue Dr. Evil) one billion seconds old. Happy gigasecond to me, happy gigasecond to me…

OK, enough frivolity. Back to boring facts about JScript .NET's coercibility algorithm.

**************************

Today I'll finish up and give a more precise definition of how JScript .NET determines whether a particular value is coercible to a given type. Then we'll get back into lighter topics.

Suppose we have a value V which we wish to coerce to type T without data loss or error. For clarity I'll split the algorithm up into two sections, one for "special" types like classes, arrays and enumerations, and one for "primitive value" types like integers and strings.

Suppose T is a reference, enumerated, array, etc, type:

If V is null or undefined then V is coercible to T irrespective of T.

If T is System.Object then V is coercible to T irrespective of V.

If T is a class and V is an instance of T (which includes being an instance of a subclass of T) then V is coercible to T.

If T is an interface and V implements T then V is coercible to T.

If T is a non-JScript array of known element type E and V is a JScript array then V is coercible to T if and only if every element of V is coercible to E.

If T is a JScript array and V is a rank-one non-JScript array then V is coercible to T.

If T is an enumerated type and V is a member of enumerated type E then V is coercible to T if and only if T and E are the same type.

If T is an enumerated type and V is a string and then V is coercible to T if and only if V names a member of T.

If T is an enumerated type of implementation type E and V is not a member of an enumerated type then V is coercible to T if and only if V is coercible to E.

If T is the System.Type type and V is a class name (not an instance of a class but actually the name of a class) then V is coercible to T.

If T is a delegate type and V is a function object (including a closure) then V is coercible to T if and only if V has the same function signature as the delegate.

If T defines an appropriate type coercion function then V is coercible to T if and only if the function call doesn't throw an exception.

Now let's consider the primitive type coercion rules.

JScript .NET supports several numeric types: 8, 16, 32 and 64 bit integers in both signed and unsigned flavours, 32 and 64 bit floats and a decimal type. JScript .NET also supports a "char" type which is an unsigned 16 bit integer that holds a single Unicode UTF-16 value. JScript .NET also supports a scalar Date/Time type which is treated the same as a signed 64 bit integer unless otherwise noted.

Note that data loss is allowed when coercing anything to Boolean and when coercing strings to numbers.

If T is the type of V then V is coercible to T. (Duh!)
If V is undefined or null then V is coercible to T irrespective of T. (FYI, coercing V to Boolean goes to false. Coercing V to any numeric type goes to 0. Coercing V to string goes to "".)
If V is Boolean then V is coercible to T irrespective of T. (FYI, coercing a V to a numeric type goes to 0 or 1, coercing V to string goes to "true" or "false".)
If V is char then V is coercible to T irrespective of T. (FYI, coercing V to Boolean goes to false if char is \u0000, true otherwise. Coercing V to numeric goes to the UTF-16 value. Coercing V to string goes to a single-character string.)
If T is any numeric type and V is a member of any numeric type then V is coercible to T if and only if V can be coerced to T without overflow or loss of precision. For instance, if V were the unsigned 8-byte integer 300 then V could be coerced to an unsigned 2-byte integer regardless of the fact that the 8-byte unsigned integer type is not promotable to the 2 byte integer type. Note that if V is, say, the 8-byte float value 0.1 then this is not coercible to a 4-byte float as there will be a loss of precision. (0.5 would be coercible.) Recall that the assignability algorithm has a special case to ensure that compile-time constants inferred to be 64 bit floats are assignable to 32 bit floats even if they are not coercible.
If T is string and V is of any numeric type then V is coercible to T. (JScript .NET uses the standard number-to-string routine. If V is a Date/Time scalar then it uses the appropriate date string.)
If T is Boolean and V is of any numeric type then V is coercible to T. (If V is zero or NaN then it goes to false, otherwise it goes to true.)
If T is Boolean and V is a string then V is coercible to T. (If V is "" then it goes to false, otherwise true.)
If T is a date type and V is a string then V is coercible to T if and only if V is parsable as a date.
If T is char and V is a string then V is coercible to T if and only if V is a single-character string.
If T is a numeric type and V is a string that can be parsed as type T then V is coercible to T
If T is a numeric type and V is a string that cannot be parsed as type T then V is coercible to T if and only if V is parsable to an 8-byte float and the resulting float value is coercible to T.

If none of the above apply, V is not coercible to T, and will likely cause a type mismatch exception.

JScript .NET Type Coercion Semantics, Part Three: Assignability

Eric Lippert — Fri, 06 Aug 2004 17:38:00 GMT

Before I begin today's technical topic, a quick link to what promises to be a terrifying, I mean, terribly interesting blog.

Mario, the guy who tests the code that I write and thereby keeps me honest, the guy who's application for a backyard barbecue was turned down by the Redmond fire department, the guy who, when I showed him how to use MSBUILD to change his security policy responded with "wonderful! If I was a woman I would kiss you... but because the lack of some features a strong handshake is more appropiate for both of us,“ -- yes, that guy has started blogging.

**********************************

Today I'll give a more precise definition of how JScript .NET determines whether one type is assignable to another. Remember, assignable is weaker than promotable -- promotable means that we are guaranteed that every instance of then source type is coercible to the target type. With assignable, we care only if some instance of the source type is coercible to the target type.

Next time, we'll finish up this incredibly boring series with the actual coercibility algorithm. Then I think I'll take a short break and talk about some lighter topics before tackling overload resolution.

Again, suppose we have an assignment of an expression to a typed field.

Left Hand Side Expression = Right Hand Side Expression;

where the compiler can infer the type of the left hand side as LHT and the right hand side as RHT. I'm going to be a little bit loose in my definition of assignable below in that sometimes I care about the type of the right hand expression, but sometimes we have more information than just the type and we want to determine whether the expression result is assignable. It should be clear from the context which way I mean it.

Unfortunately, the current release of JScript .NET has a number of bugs -- it appears that the compiler does not actually enforce some of these rules at compile time when it could. Assigning bad constant strings to enumerated types, for example, isn't caught until runtime. Neither is the rule for double->single conversions. Weird. I'll mention those to the JScript .NET dev next time I see him.

We start with three broad categories:

RH Expression is a compile-time constant.
RH Expression is an array literal.
RH Expression is something else.

RHExp is a compile-time constant

This is clearly the simplest case. We know not only the type but the value, so the question of whether RHT is assignable to LHT or not is irrelevant. All we care about is whether this specific expression is assignable.

If constant RHExp is the name of a class then RHExp is assignable to LHT if and only if LHT is System.Type or System.Object.
If LHT is an enumerated type and RHExp is a string then RHExp is assignable to LHT if and only if the string names a member of that enumerated type.
If the constant RHExp is coercible to type LHT then it is assignable. (More on this next time.)
If RHExp is a numeric literal and RHT is 8-byte float and LHT is a 4-byte float then RHExp is assignable to LHT. Yes, this is potentially lossy, but there's not much else we can do, so be careful! However…
If RHExp is a compile-time constant 8-byte float but NOT a numeric literal and LHT is a 4-byte float then RHExp is assignable to LHT if and only if the string representation of the double and the string representation of that double downcast to single are identical. (Oddly enough, this rule doesn't seem to be enforced by the compiler. Looks like a bug.)

RHExp is an array literal

Array literals are weird because they are treated as JScript arrays or system arrays depending on the context. It matters very little what specifically RHExp is to determine assignment compatibility:

If LHT is System.Object or System.Array or JScript array then RHExp is assignable to LHT
If LHT is not some kind of array then RHExp is not assignable to LHT
If LHT is an array type of known rank and that rank is not 1 then RHExp is not assignable to LHT
If LHT is an array of known type ElemType then RHExp is assignable to LHType if and only if every element in the array literal is assignable to ElemType.

RHExp is something else.

If LHT is System.Object then RHT is assignable to LHT.
If LHT any primitive numeric type and RHT is 8-byte float then RHT is assignable to LHT.
If RHT is promotable to LHT then obviously RHT is assignable to LHT.
If LHT is a delegate and RHExp is a signature-compatible script function then RHExp is assignable to LHT.
If LHT is not any kind of array and RHT is JScript array then RHT is not assignable to LHT.
If LHT is System.Array and RHT is JScript array then RHT is assignable to LHT. (I believe this gives a warning though.)
If LHT is an array type known to be rank 1 and RHT is JScript array then RHT is assignable to LHT.
If LHT is an array type known to be rank other than 1 and RHT is JScript array then RHT is not assignable to LHT.
If LHT is string then RHT is assignable -- just about everything can be converted to string.
If LHT is Boolean or any primitive numeric type and RHT is string then RHT is assignable to LHT.
If LHT is char and RHT is string then RHT is assignable to LHT.
If LHT is promotable to RHT then RHT is assignable to LHT. For instance, base classes are assignable to derived classes even though they are not promotable.
If LHT and RHT are both primitive numeric types then RHT is assignable to LHT.

Those last four may give a compile-time warning, as they're pretty dodgy.

JScript .NET Type Coercion Semantics, Part Two: Promotability

Eric Lippert — Thu, 05 Aug 2004 00:49:00 GMT

Last time I gave some vague, high-level definitions of the type system concepts promotable, assignable and coercible. Today I'll give a more precise definition of promotable. The others I'll define more precisely later.

Suppose we have an assignment of an expression to a typed field.

Left Hand Side Expression = Right Hand Side Expression;

where the compiler can infer the type of the left hand side as LHT and the right hand side as RHT. RHT is promotable to LHT if every member of RHT is coercible to LHT.

There are, as you'll see, some bugs and weirdnesses in JScript .NET's implementation of the promotability algorithm. This describes how it is, not how it should be!

In this list of rules there are some contradictions -- in those cases, earlier rules supercede later rules.

General rules

If LHT is the same type as RHT then RHT is trivially promotable to LHT.
If LHT is System.Object and RHT is a passed-by-reference type then RHT is not promotable to LHT
If LHT is System.Object and RHT is anything other than a passed-by-reference type then RHT is promotable to LHT
If LHT is any non-array type and RHT is an array type then RHT is not promotable to LHT.
If LHT is any array type then see the algorithm below.
If LHT or RHT is an enumerated type then see the algorithm below.
If either RHT or LHT is a class/interface then see the algorithm below.
If RHT is the (single-member) undefined type or the (single member) null type then RHT is promotable to LHT regardless of what LHT is.
If LHT and RHT are both primitive Boolean, numeric or date types (Boolean, 1/2/4/8 byte signed/unsigned integers, 4/8 byte floats, decimal, datetime, timespan), see the algorithm below.
If LHT is a JScript object wrapper for Boolean or string and RHT is the corresponding primitive type then RHT is promotable to LHT.
If LHT is the JScript object wrapper for number and RHT is promotable to a primitive 8-byte float then RHT is promotable to LHT.
If LHT is the primitive Boolean, string or datetime and RHT is the corresponding wrapper type then RHT is promotable to LHT.
If LHT is a primitive integer or float and RHT is the wrapper type for number then RHT is promotable to LHT. (This one is an exception, as it is potentially lossy.)
If LHT has defined an implicit cast operator from RHT then RHT is promotable to LHT.
If RHT has defined an implicit cast operator to LHT then RHT is promotable to LHT.
Otherwise, RHT is not promotable to LHT.

Rules for the case where LHT is an array type

If LHT is any array type and RHT is not an array type then RHT is not promotable to LHT.
If LHT is not a JScript array and RHT is a JScript array then RHT is not promotable to LHT.
If LHT is System.Array then RHT is promotable to LHT, regardless of RHT.
If LHT is any array type and RHT is System.Array then RHT is not promotable to LHT.
If LHT is a JScript array and RHT is any array known to be of rank 1 then RHT is promotable to LHT. Note that this is an exception, as it is potentially lossy or error-prone.
If LHT is of known type and rank and RHT is of known type and rank, and furthermore, the ranks are equal and RHT is Element Type Compatible with LHT then RHT is promotable to LHT.
Otherwise, RHT is not promotable to LHT.

Rules for the case where LHT or RHT is an enumerated type

If LHT and RHT are different enumerated types then RHT is not promotable to LHT.
If LHT is an enumerated type and RHT is a primitive numeric type promotable to the underlying numeric type of LHT them RHT is promotable to LHT.
If LHT is a primitive numeric type and RHT is an enumerated type whose underlying numeric type is promotable to LHT, then RHT is promotable to LHT.
If LHT is an enumerated type and RHT is string then RHT is promotable to LHT.
Otherwise, RHT is not promotable to LHT.

Note that the rules for enumerated types are exceptions; clearly there are always strings and numbers which are not coercible to a given enumerated type!

Rules for the case where RHT or LHT is a class/interface

If LHT is a superclass of RHT then RHT is promotable to LHT.
If LHT is an interface implemented by RHT then RHT is promotable to LHT.
Otherwise, RHT is not promotable to LHT.

Rules for the case where RHT and LHT are both primitive types

If RHT is Boolean or unsigned 1-byte integer and LHT is char, any integer, float, decimal, datetime or timespan then RHT is promotable to LHT.
If RHT is char or unsigned 2-byte integer and LHT is 2-byte unsigned integer, any 4 or 8 byte integer, float, decimal, datetime or timespan then RHT is promotable to LHT.
If RHT is signed 1/2-byte integer and LHT is any signed integer, any float, decimal, datetime or timespan then RHT is promotable to LHT. (This appears to be buggy -- a signed 2-byte integer should not be promotable to a signed 1-byte integer! I'll look into it.)
If RHT is signed 4-byte integer and LHT is signed 8-byte integer, 8-byte float, decimal, datetime or timespan then RHT is promotable to LHT.
If RHT is unsigned 4-byte integer and LHT is any 8-byte integer, 8-byte float, decimal, datetime or timespan then RHT is promotable to LHT.
If RHT is any 8-byte integer and LHT is decimal, datetime or timespan then RHT is promotable to LHT.
If RHT is any float and LHT is 8-byte float or decimal then RHT is promotable to LHT.
Otherwise, RHT is not promotable to LHT.

Next time, assignability.

JScript .NET Type Coercion Semantics

Eric Lippert — Mon, 02 Aug 2004 22:19:00 GMT

Stan Lippman has started an interesting series of blog entries on how Managed C++ determines which function foo to call when you call foo(bar) given that there may be several visible functions of that name in the current scope. That's quite coincidental, as just the other day I was going through some old mail when I found a long document I wrote up on how JScript .NET does this.

In the unlikely event that anyone out there is interested, I think I'll post bits of it over the next few days. The compare-and-contrast with C++ might be edifying. (Yes, this is going to be pretty geeky, even for me.)

To begin with, I want to start by tackling a different question -- how does JScript .NET handle the situation where a value of one type is assigned to a field, where the field has a type restriction? For instance, how do we handle the situation

var blah : String = 123;

? In particular, we are concerned with the implicit type coercions. Explicit type coercions like

var blah : String = String(foo);

Are obviously less interesting, as the compiler does not have any particular work to do -- it just lets the run-time coercion function do its work.

Recall that a type is defined as a set of values, plus a set of rules for converting any values not in that set to a value in the set. (That rule may include "throw a type mismatch exception" of course!) For a quick refresher on the JScript and JScript .NET type systems in general, I wrote a whole series of articles starting here.

Under what circumstances are coercions performed?

The JScript .NET compiler can perform some type coercions at compile time. For instance, compile-time constants such as the above case can be converted by the compiler. But that's a pretty rare case. The more common case is that the types are known at compile time but the values are not. (In the worst possible late-bound case the types are not known until runtime and special late-bound helper functions must be invoked. In general, the late-bound functions should have the same behaviour as if the types and values were known at compile time.)

There are many situations in JScript .NET where the compiler must generate a type coercion. The most common cases are:

An explicit conversion (see above)
When assigning a value to a typed variable
When passing arguments to a function with typed arguments
When indexing an array
When setting a typed global value, local value or member value using an assignment operator (=, +=, etc).
When a function with a type annotation on its return type returns a value
Some operators cause arguments to be coerced, eg, (foo + "") coerces foo to string. Bitshift operators coerce arguments to 32 bit integers, etc.

There are also a few more obscure scenarios:

When passing arguments to a custom attribute.
If a JScript array is coerced to a System.Array then each member of the JScript array is coerced to the element type of the System.Array.
If a System.Array is coerced to a JScript array then we wrap the System.Array with a JScript array wrapper. Setting values on the JScript array wrapper automatically coerces the value to the element type of the underlying System.array. (See here, here, here, here and here for more information about the relationship between the two kinds of array.)
When subtracting anumber from a char the result is coerced to char -- I'll do another blog entry sometime on all the interesting semantics of the char type in JScript .NET.

How do we determine at compile time when an implicit coercion is legal?

I need some definitions.

By "VALUE is coercible to TYPE" I mean that the specific VALUE may be coerced to TYPE without data loss or error.

For example, the value 0.5 is coercible to the type "32 bit floating point number" but not to the type "32 bit signed integer". (There are a few exceptions, in that some lossy coercions are still considered coercible -- numbers are considered coercible to Boolean, for instance.)

By "TYPE_1 is promotable to TYPE_2" I mean that every member of TYPE_1 is coercible to TYPE_2.

For example: the type "32 bit signed integer" is promotable to "64 bit float" but not promotable to "32 bit float". Note that this implies that any derived class is promotable to one of its base classes, and value types are always promotable to their boxed types.

By "TYPE_1 is assignable to TYPE_2" I mean that there exists at least one member of TYPE_1 which is coercible to TYPE_2.

Clearly, if TYPE_1 is assignable to TYPE_2 but not promotable then there must be some member of TYPE_1 which is lossy or produces an error when coerced to TYPE_2. The JScript .NET compiler will often issue a warning if the program contains an assignment entailing an implicit coercion between types known to be assignable but not promotable. For example: since zero is common to all numeric types, all numeric types are assignable to each other. A base class is assignable to a derived class and vice-versa. But Array is not assignable to Number.

Finally, a definition that will come in handy tomorrow: consider two typed array types, TYPE_1 and TYPE_2, where their elements are of type ETYPE_1 and ETYPE2, respectively. By "TYPE_1 is element-type-compatible (ETC) to TYPE_2" I mean:

If either ETYPE_1 or ETYPE_2 is a value type then TYPE_1 is ETC with TYPE_2 if and only if ETYPE_1 = ETYPE_2. int[] is not ETC with long[]
If neither ETYPE_1 nor ETYPE_2 are value types then TYPE_1 is ETC with TYPE_2 if and only if ETYPE_1 is promotable to ETYPE_2.

OK, enough definitions. Why "assignable"? Because generally speaking, we can consider the pattern

Left Hand Side Expression = Right Hand Side Expression;

as the canonical situation in which a type coercion is performed. When passing arguments to function calls, that's basically a kind of assignment. From now on we'll just talk about assignment coercions.

The JScript .NET compiler determines the types of the LHS and RHS expressions at compile time as best it can and then checks to see if the RHS expression's type is assignable to the LHS expression's type. If is it then it generates an implicit coercion. If it's assignable but not promotable, that's usually a warning, and if it is not assignable at all then that's usually a compile-time error.

Next time I'll go into much more detail as to how the compiler determines promotability, assignability and coercibility.

A JScript .NET Design Donnybrook, Part Two

Eric Lippert — Tue, 08 Jun 2004 21:01:00 GMT

I am totally amused that the comments on yesterday's entry are nigh-isomorphic to the argument that we had over this in October 2000. As noted, f.bar(f); does in fact call the base class function, not the derived class function as some might expect.

I was on the fence back in 2000, but leaning towards the derived class, as was most of the rest of the team. Peter Torr was leaning towards the base class, and Herman, the architect, was pretty clearly in the base class camp. My argument was pretty similar to the arguments that most of you guys raised yesterday. In short, I cleaved to the principle:

Calls to methods on objects of unknown type should have the same semantics as if the type was known to be the most derived type. If developers want to restrict a call to a method on a particular type, they can add the annotation.

Though that is clearly a decent principle, in this situation it conflicts with some other design principles, such as:

JScript is all about guessing what the developer meant to say, and muddling on through if it's not clear.

and

Class-based code is a more-strictly-typed alternative to dynamic prototype-based code, and therefore class semantics should opt for increased type safety and efficiency rather than increased dynamism.

It really comes down to guessing what the developer meant. My example was deliberately abstract. Consider a more realistic example. In Canada, there's a Goods and Services Tax which is rather complicated. There are situations where a cake is taxable if you sell it in a restaurant, but not taxable if you sell it in a grocery store. (The rules are considerably more complex than that -- my father owned a restaurant at the time this tax became law, and figuring out when a single muffin vs a box of muffins was taxable was quite tricky.)

class Grocery {
function get tax() {
return 0;
}

function PrintTaxrate(item) {
print(item.tax);
}
}

class Cake extends Grocery {
hide function get tax() {
return 7;
}
}

Here the meaning of the "hide" is "if a cake is being treated as a cake, it's taxable. If it is being treated as a grocery item, it's not taxable."

But uh-oh, the developer of the base class did not annotate the method as taking a Grocery.

Now, suppose that you are developing the Cake class. The Grocery class already exists, and you are extending it -- perhaps the base class is even in an entirely different package. The developer of the Grocery class has forgotten to annotate the method, not anticipating that someone might have a non-virtual override. In order to enable the developer of the Cake class to implement the desired semantics, the code gen for the Grocery class must as its first guess assume that the caller intended this thing to take a Grocery.

Clearly there are arguments on both sides; it's a judgment call whenever you have to guess what the user meant.

Another advantage of this approach is that it is more efficient. Calling late-bound is very inefficient compared to speculatively casting the object to a class, and calling the method if the cast succeeds. The cost of late binding is enormous, and we wanted to do everything possible to eliminate it while still keeping the language scripty.

Therefore what the code gen does in this case is looks for every visible class which has the appropriate method, and generates a cast-and-call for each, and finally bottoms out to do the late-bound call if none of the casts worked. Unless you have a large number of visible classes with the same method names, this is pretty darn efficient. If you choose to always call the most derived type's method then there is no way to generate this code efficiently because you always must do the late bound call first.

Philip Rieck's head exploded shortly after he discovered that the generated code actually checks to see if the argument is an instance of base, and THEN checks to see if it is an instance of derived. Isn't that unreachable code? Put your head back together Philip. Yes, it appears to be a codegen bug. I can't think of any circumstance in which that would not be dead code. I'll mention it to the JScript .NET team the next time I see him.

Peter Torr might remember more reasons than I do why we chose to do it this way. Peter?

A JScript .NET Design Donnybrook

Eric Lippert — Mon, 07 Jun 2004 21:15:00 GMT

When you're designing a new programming language, the "main line" cases are easy. It's the "corner" cases that bedevil language designers -- the little fiddly bits where two language features that make perfect sense on their own interact in some weird way. Unfortunately, I suspect that any language sufficiently feature-rich to be interesting will have weird corner cases. Getting them right is one of the more interesting and difficult aspects of language design.

Want to give it a try yourself? Now's your chance. Here is a question that sparked a protracted and hilarious debate amongst the JScript .NET design team back in 2000. I'd be interested to see what your opinions are. So as to not spoil the fun, figure out what you think this code should do before you run it or decompile it into IL.

class foo {
function get abc() {
    return 5;
}
}
class foo2 extends foo {
function bar(ob) {
    print(ob.abc);
}
}
class foo3 extends foo2 {
hide function get abc() {
    return 50;
}
}
var f = new foo3();

Clearly print(f.abc); must print out 50. But should f.bar(f); print out 50 or 5?

Justify your answer.

HINT: While you're thinking it over, keep in mind that nowhere in this code are there any type annotations. The question was originally raised in the context of speculative compiler optimizations which we might perform in the absence of type annotations. Are there codegen optimizations which we could perform that make your desired behaviour more efficient in common cases?

JScript .NET Classes Are Serializable -- Surprise!

Eric Lippert — Thu, 27 May 2004 00:29:00 GMT

You learn something new every day in this job. Or, more accurately, some days you learn things again that you'd forgotten years ago.

Someone just asked me why it is that all JScript .NET classes are serializable. I admit it, my first reaction was "They are?" But I checked the sources, wrote some code and ran it through ILDASM and sure enough, all JScript .NET classes ARE serializable!

Though I did not write that code, surely I must have known that at some point. Now that I think about it a bit more, it's coming back to me. I think the idea was that the designers anticipated that there would often be situations in which JScript.NET objects would have to be passed across appdomains. (Exceptions for instance -- in JScript, you can throw anything.) That means either making classes marshal-by-ref or serializable, and apparently we picked serializable.

We could of course have gone the other way, and made developers figure out which classes needed to be serialized, and defaulted to “not serializable“. But one of the major JScript .NET design principles is "just get it done, already!" C# was designed so that most of the defaults limit behaviour -- things are private until made public, and so on. In JScript .NET, as much as possible is left open; if you want to tighten it up, you go right ahead. This is in keeping with the scripty nature of the language, while still recognizing that people do write large programs in script languages.

If for some reason you wish a class to be not serializable then you can do this:

public System.NotSerialized class MyClass {

(Notice that in JScript .NET, you don't need to put ugly brackets around attributes. The parser is smart enough to figure out that there is an attribute before the class declaration. However, this significantly complicates the parser; I see why C# and VB.NET require their delimeters.)

Offhand I don't see anywhere on MSDN where this feature is documented, though it is possible that my google-fu has failed me.

Eval is Evil, Part Three

Eric Lippert — Mon, 26 Jan 2004 19:13:00 GMT

Recall that in Part One we discussed eval on the client, and in Part Two we discussed eval on the server. Today, I answer a question about eval in JScript .NET. Someone sent me mail the other day asking why this C# program snippet didn't work:

x = Microsoft.JScript.GlobalObject.eval("1");

This throws a seemingly bizarre exception.

Microsoft.JScript.JScriptException: Eval may not be called via an alias

What's up with that? Well, remember that eval parses and executes a program snippet in the context of an existing runtime state.

For example, consider this JScript program:

var x = 123;
var y = eval("x + 10");

How does eval know to return 133? eval needs to know what the current state of the runtime is -- what all the variable bindings are, what scope it is presently in, all that kind of stuff. You can't just up and call a general purpose evaluation engine from no context whatsoever. Eval isn't a calculator! It's deeply integrated with the JScript .NET runtime.

If you want to call eval, there are only two legal ways to do so

1) Write a JScript .NET program that calls eval explicitly.
2) Construct a VsaEngine containing the desired runtime state, and then call the public static function Eval.JScriptEvaluate(source, engine).

I don't recommend the second option unless you really know what you are doing.

But what's up with that bizarre exception? Actually, the exception was not designed to catch people trying to call eval without a runtime context. Though that certainly is a nice side effect, we would have made the error message a little more clear had this been the primary scenario!

An eval precludes certain compiler optimizations, so we must detect at compile time whether a given scope contains an eval. Easy -- just look for calls to that function, right? But you could get around that by aliasing eval. Remember, JScript has first class functions, so nothing stops you from saying

function foo(x)
{
    var abc = 123;
    // The compiler detects that only numbers are
    // assigned to abc and optimizes accordingly
    x("abc = 'hello';");
    // but if x is eval then the optimization is incorrect
    // ...
}
foo(eval);

We have no way of determining whether or not foo contains a call to eval. Therefore we made aliasing eval illegal. Now the exception makes sense: Eval may not be called via an alias. The program above produces that exception.

But why is this exception thrown when a C# programmer tries this?

x = Microsoft.JScript.GlobalObject.eval("1");

Because if the compiler finds a call to eval, it generates a special function call node in the abstract syntax tree which generates different code than the general purpose function call node that would be generated for the case above. When you say in JScript .NET

eval(whatever);

then the compiler generates a call to Eval.JScriptEvaluate(source, engine). After all, the compiler knows where the VsaEngine state is. But if you get a reference to eval via the global object -- either directly in the C# case, or indirectly in the JScript .NET case -- then you get a dummy function that just throws an exception.

There are also security implications to using eval in JScript .NET which I will get into in a future post.

Virtual Methods and Brittle Base Classes

Eric Lippert — Wed, 07 Jan 2004 23:28:00 GMT

Hey, I'm back! And in my new location.

That was the longest and least relaxing vacation I've ever taken. Fun, yes. Relaxing, no. And to top it off, my kitchen is not done yet. We're shooting for being able to run water tonight and actually use appliances by tomorrow night, but we'll see how it goes.

Well, enough chit-chat. I wanted to talk a little about the brittle-base-class problem, and how JScript .NET deals with it.

Virtual Methods and Brittle Base Classes

One of the challenges inherent in writing larger programs is managing change over time. Few large programs are written once and never updated. Usually new features are implemented for new versions. Class-based programming allows for clean, object-oriented design but there are still some pitfalls to be wary of. One of the more insidious object-oriented programming pitfalls is the brittle base class problem. Here's how it usually goes:

You develop a very useful class for version one of your project. You have a "gadget" which can be "confusticated":

// Project Juliet Version 1
class Gadget {
public function confusticate() { // . . .

Some coworkers working on another application at your company realize that their "widgets" are a special case of your gadgets, so they subclass. After all, code re-use is one of the benefits of object-oriented programming. These particular widgets need to be "garbled", so they add a new method:

// Project Romeo Version 1
class Widget extends Gadget {
public function garble( ) { // . . .

A widget is confusticated the same as a gadget, thus they do not override the confusticate method. They get your library, compile up their code, test everything out and it is all good.

Six months after version one of your project ships you are hard at work developing the next version. In this version you have decided that gadgets can be garbled too. Furthermore, you decide that any confusticated gadget needs to also be garbled, so you modify your sources:

// Project Juliet Version 2
class Gadget {
public function garble() { // . . .
public function confusticate() {
this.garble();
// . . .

You have no idea that your coworkers have extended your class and already added a method to garble a widget. Furthermore, they do not necessarily know that you have changed the base class. That could be a very small change amongst thousands of lines of code and many other changes. Now what happens when they call confusticate on one of their widgets? The base class's confusticate method is called, but because garble is virtual it then calls the derived class's garble method.

There are two ways that could be seriously wrong. First of all, you might have implemented the base class fully expecting that the gadget garbling method would be called upon confustication, but now the widget garbling is performed. Second, the widget implementers have no idea that confusticating can cause garbling. From their perspective the only code that can call garble is their code! As far as they know they are the only ones who have written a garbling method.

"Base" classes are well-named -- the behaviour of the derived classes depends upon the base classes having rock-solid behaviour. If the base class implementations are brittle, then the derived classes will not be robust either. This is just one brittle base class scenario; there are many variations on this scenario.

One way to prevent the brittle base class problem is to use assembly manifests and config files to ensure that you always bind against the version you tested against. But in the spirit of providing the flexibility of multiple solutions, JScript .NET also affords some techniques to mitigate the rittle base class problem.

Trapping the Error: The Versionsafe Switch

The lesson here is that every time you change a base class you have to test not only the base class but every single derived class. There really is no getting around that fundamental fact but there is a tool which can help in this particular situation. If you run the JSC compiler with /versionsafe then the potential disaster described above will not be averted but it will at least be brought to your attention. Specifying this flag makes it illegal to make a virtual function by accident. In other words, it changes the default behavior from "make a function with the same signature as a base class function an overriding virtual function" to " make a function with the same signature as a base class function an error."

That means that when the people working on Project Romeo version 2 go to compile up the Widget class using the new Gadget they will immediately get an error. You have added a garble method which matches the signature in a base class and they must therefore explicitly say whether their matching method is a virtual (override) or a non-virtual (hide) method. Which solution is correct depends on the semantics of all the interacting methods; the point is to flag the potential problem automatically rather than using a default behavior which might be incorrect.

Preventing the Subclassing

The crux of the brittle base class problem is that the providers of the base and derived classes each have no idea what the other is doing. It is extremely annoying to have bugs crop up that seem to be in your code because someone else did a poor job of writing a subclass. It is possible and indeed highly desirable to simply not let anyone subclass your classes without a compelling reason.

The attribute final is used to indicate that a class may not be subclassed in JScript .NET:

final class Gadget
{ /* . . . */ }

Now when your coworkers try this, they get an error:

class Widget extends Gadget // Error, Type Gadget may not be extended
{ /* . . . */ }

It might be the case that you do want Gadget to be extendible but do not want a particular method to be overridden. To do this you can make individual functions final:

class Gadget {
final public function Garble() { // . . .
}

class Widget extends Gadget { // OK, Gadget is not final
override public function Garble() { // Error, Garble is final

Note that it is legal to hide a final base class method. It is only illegal to override a final base class method.

Another technique would be to use inheritance demands, but that's a topic for another day.

The JScript Type System Part Eight: The Last Blog Entry About Arrays, I Promise

Eric Lippert — Fri, 05 Dec 2003 21:12:00 GMT

Recall that I defined a type as consisting of two things: a set of values, and a rule for associating values outside of that set with values inside the set. In JScript .NET, assigning a value outside of a type to a variable annotated with that type restriction does that coercion if possible

var s : String = 123; // Converts 123 to a String

Similarly, I already discussed what happens when you assign a JScript array to a hard-typed CLR array variable

var sysarr : int[] = [10, 20, 30]; // Create new int[3] and copy

and what happens when you assign a one-dimensional CLR array to a JScript array variable:

var jsarr : Array = sysarr; // Wrap sysarr

But what happens when you assign a hard-typed CLR array to a variable annotated with a different CLR array type?

var intarr : int[] = [10, 20, 30];

var strarr : String[] = intarr;

You might think that this does the string coercion on every element, but in fact this is simply not legal. Rather than creating a copy with every element coerced to the proper type, the compiler simply gives up and says that these are not type compatible. If you find yourself in this situation then you will simply have to write the code to do the copy for you. Something like this would work:

function copyarr(source : System.Array) : String[]

{

var dest : String[] = new String[source.Length];

for(var index : int in source)

dest[index] = source.GetValue(index);

return dest;

}

There are a few notable things about this example. First, notice that this copies a rank-one array of any element type to an array of strings. This is one of the times when it comes in handy to have the System.Array "any hard-typed array" type!

Second, notice that you can use the for-in loop with hard-typed CLR arrays. The for-in loop enumerates all the indices of an array rather than the contents of the array. Since CLR arrays are always indexed by integers the index can be annotated as an int. The loop above is effectively the same as

for (var index : int = 0 ; index < source.Length ; ++index)

but the for-in syntax is less verbose and possibly more clear.

Third, you might recall that GetValue (and SetValue) take an array of indices because the array might be multidimensional. But we're not passing in an array here. Fortunately, you can also pass only the index if it is a single-dimensional array.

Generally speaking, hard-typed array types are incompatible with each other. There is an exception to this rule, which I'll discuss later when I talk about what exactly "subclassing" means in JScript .NET.