A JScript .NET Design Donnybrook

Method Hiding Apologia

Fabulous Adventures In Coding — Wed, 27 May 2009 08:17:56 GMT

Here's some back-and-forth from an email conversation I had with a user a while back. Why should one

re: A JScript .NET Design Donnybrook

Jeroen Frijters — Wed, 09 Jun 2004 08:33:00 GMT

>>Also, an empty cctor is not inefficient. The jitter will optimize it away.<<

I didn't know that! Thanks for setting me straight and I apologise for the snide remark.

A JScript .NET Design Donnybrook, Part Two

Fabulous Adventures In Coding — Wed, 09 Jun 2004 00:02:00 GMT

re: A JScript .NET Design Donnybrook

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

Also, an empty cctor is not inefficient. The jitter will optimize it away.

I suspect that there really was no good reason to always generate the cctor even when it was empty -- perhaps it just worked out easier to write the codegen that way.

re: A JScript .NET Design Donnybrook

Peter Torr — Tue, 08 Jun 2004 21:33:00 GMT

Jeroen: I'm pretty sure that every type has a .cctor (even if it is empty) because it made the code generator much easier. When the compiler / runtime can both compile any valid program into IL *OR* dynamically interpret it, this becomes very important.

Philip: The reason it checks for foo2 before foo3 is that we _assume_ (ha ha ha) that the developer of foo2.bar only knew about objects of type foo2 when [s]he wrote the code; they were not expecting someone else to come along, subclass their type, and add some other random method to it.

If they expected this kind of tomfoolery, they would have used a type annotation (or so the thinking went).

Basically performance of minimally-tweaked legacy JScript code was REALLY REALLY important for us in ASP .NET (who would upgrade if their pages were slower?) so trade offs like this were made.

Interestingly, this chain of things-JScript-looks-for on a late bound call can get arbitrarily long, and it's *still* going to be faster than the latebound call in all reasonable cases. isinst is fast compared to InvokeMember ;-)

re: A JScript .NET Design Donnybrook

Jeroen Frijters — Tue, 08 Jun 2004 08:46:00 GMT

Yuck. My mind just isn't capable of understanding scripting languages.

BTW, why on earth does every type have a .cctor? I know script is supposed to be inefficient, but isn't this going over the top? ;-)

re: A JScript .NET Design Donnybrook

Nicholas Allen — Tue, 08 Jun 2004 05:56:00 GMT

I stayed out of this one since I already knew the answer and mostly why it became that way. But I enjoy the quirkyness. Java also lives in this shadow world between the Static and Dynamic models. You can write a very similar piece of code to this and get the same behavior.

re: A JScript .NET Design Donnybrook

Centaur — Tue, 08 Jun 2004 05:06:00 GMT

I’m not much into JScript, and would expect 5. Because in the languages I have seen “hide” (by any other name, such as “reintroduce” in Delphi, “new” in C#) it breaks the override chain. The foo3::`get abc`() no longer overrides foo::`get abc`, and as such, will not be considered candidate for late binding.

Of course, the “scripty” thing to do, in absence of knowledge about the type of f, would be to invoke abc by name, and that would probably resolve to foo3::`get abc`. In fact, one might try this:

class baz { // totally unrelated to foo
function get abc() {
return 42;
}
}
f = new foo3();
b = new baz();
f.bar(b);

and expect 42.

re: A JScript .NET Design Donnybrook

Eric Lippert — Tue, 08 Jun 2004 02:31:00 GMT

> For those cases where I *want* stricter checking (and allow for early binding optimizations), I would tend to add the appropriate annotation

Quite amusing. I said almost exactly the same thing back in 2000. I'll blog more about this tomorrow.

re: A JScript .NET Design Donnybrook

James Hugard — Tue, 08 Jun 2004 02:14:00 GMT

Eric said:

> Ah, but remember that I've blogged before
> that one of the design principles of JScript
> is "muddle on through".

True.

In that case (and after reading the docs on "hide"), I would say 50.

Why? Because, again due to the philosophy of the previous version of JScript (and script languages in general), I would expect a late-bindy kind of behavior. In the absence of a type specifier (e.g., for an Object), I would *always* perform/expect late-binding of method calls.

Yes, this results in *much* slower code for the typical case, but it would be in line with my expectations.

> However, remember that we added class
> inheritance to strengthen the type system
> so that people who wanted a more predictable,
> static, type-checked experience could have one.

For those cases where I *want* stricter checking (and allow for early binding optimizations), I would tend to add the appropriate annotation. Actually, I would have preferred (would still like) a compiler switch to require strict specification of type. In fact, before Jscript was released I would have argued for it as an effect of –fast. Today, it would be nice as its own switch.

IMHO, an answer of 5 would make a compiler writer happy (it results in faster early-bound code) and an answer of "50" would make a user happy (it is what I, personally, would expect).

Yes… I am surprised that the answer is in fact 5 :P

Anyway, when it comes to the new Jscript.net features, I will now start out suspecting that the compiler will try to do the “fast” thing instead of the “scripty” thing; in this case, use the type in effect at the time of definition and do early binding. Without giving it much thought, I would not be surprised to learn that this follows the model of other CLI languages (none of which I know very well).