The JScript Type System, Part Two: Prototypes and constructors

RE: The JScript Type System, Part Two: Prototypes and constructors

Erik Arvidsson — Thu, 06 Nov 2003 22:40:00 GMT

Just a side note. The prototype object is usually called __proto__ ( [[Protoype]] in the spec) and almost all ECMAScript engines (except the Microsoft ones) allows read write of this private property.

RE: The JScript Type System, Part Two: Prototypes and constructors

Jay Hugard — Fri, 07 Nov 2003 02:01:00 GMT

Can you explain the logic behind the following madness (in JScript Classic), which appears to mean that a string is not always a String but a regexp is always a RegExp? Conversly, what is the recommended way of determining if a value is a string? slit instanceof String => false sobj instanceof String => true slit instanceof Object => false sobj instanceof Object => true typeof( slit ) => string typeof( sobj ) => object typeof( slit ) == typeof( sobj ) => false relit instanceof RegExp => true reobj instanceof RegExp => true relit instanceof Object => true reobj instanceof Object => true typeof( relit ) => object typeof( reobj ) => object typeof( relit ) == typeof( reobj ) => true As generated by: function println(s) { WScript.echo(s) /*System.Console.Out.WriteLine(s)*/ } function evalprintln( s ) { if( !s ) { println(""); return } var out = s + " => "; try{ out += eval(s) } catch( e ) { out += "Error: " + e.description } println(out); } var slit = "Literal String"; var sobj = new String( "String object" ); var relit = /literal regexp/i var reobj = new RegExp( "RegExp object" ); var tests = [ "slit instanceof String", "sobj instanceof String", "slit instanceof Object", "sobj instanceof Object", "typeof( slit )", "typeof( sobj )", "typeof( slit ) == typeof( sobj )", null, "relit instanceof RegExp", "reobj instanceof RegExp", "relit instanceof Object", "reobj instanceof Object", "typeof( relit )", "typeof( reobj )", "typeof( relit ) == typeof( reobj )" ]; for( var ix in tests ) { evalprintln( tests[ix] ) }

RE: The JScript Type System, Part Two: Prototypes and constructors

Peter Torr — Fri, 07 Nov 2003 02:32:00 GMT

Erik -- IIRC, Netscape removed the support for __proto__ from their engine some years ago because it was a bad idea to let people mess with the prototype chain this way. The ECMA standard does not require the property to be exposed, and it is dangerous to do so.

RE: The JScript Type System, Part Two: Prototypes and constructors

Peter Torr — Fri, 07 Nov 2003 02:40:00 GMT

Jay, if you read the ECMA spec you will see that there are string primitives and string objects, just as there are number/boolean primitives and number/boolean objects. Basically you should never use "new String(...)" because it is a waste of time and energy. var nlit = 42 var nobj = new Number(42) print(nlit instanceof Number) print(nlit instanceof Object) print(nobj instanceof Number) print(nobj instanceof Object)

RE: The JScript Type System, Part Two: Prototypes and constructors

IUnknown — Fri, 07 Nov 2003 10:02:00 GMT

>JScript, unlike VBScript, does not interrogate COM objects to determine >the class name. This gets the award for the most unrelated error message: TypeName(myObject) throws, when the type information is unavailable: Out Of string space: 'TypeName'

RE: The JScript Type System, Part Two: Prototypes and constructors

Eric Lippert — Fri, 07 Nov 2003 20:54:00 GMT

Can I see a repro for that? If the type name is unavailable, it should return "Unknown" or, if it is an IDispatch, "Object". TypeName does return "Out of string space", but only when the attempt to allocate the string for the type name fails.

RE: The JScript Type System, Part Two: Prototypes and constructors

Erik Arvidsson — Fri, 07 Nov 2003 23:14:00 GMT

Peter: I know both the Mozilla engines (C and Java) and the Macromedia engine has support for this. I was pretty sure that Opera supported this as well but I just verifed that they do not. I can understand why it is considered dangerous but usage of __proto__ can be very useful. For example it allows you to skip creating an instance that is used as the prototype. fucntion SubClass( args ) { SuperClass.call( args ); } SubClass.prototype.__proto__ = SuperClass.prototype; Well, well... now that we have ECMAScript v4 around the corner there is no real need for this.

RE: The JScript Type System, Part Two: Prototypes and constructors

Eric Lippert — Sat, 08 Nov 2003 01:02:00 GMT

> Well, well... now that we have ECMAScript v4 around the corner there is no real need for this. That's news to me. Could you more precisely define "around the corner"?

RE: The JScript Type System, Part Two: Prototypes and constructors

Isaac — Sat, 08 Nov 2003 01:26:00 GMT

> conflated static typing with strong typing "static typing" unhelpfully confuses when checks are made with the kind of checks that are made. Simpler to understand that C++ is a statically-checked weakly-typed language (and also that some things are dynamically checked in C++). Simpler to understand that JScript is a dynamically-checked untyped (safe?) language. I think you demonstrated that it's pretty hard to figure out what the type of a value is in JScript - so why insist on calling it a typed language?

RE: The JScript Type System, Part Two: Prototypes and constructors

Anonymous — Sat, 08 Nov 2003 14:05:00 GMT

[quote]Can I see a repro for that? If the type name is unavailable, it should return "Unknown" or, if it is an IDispatch, "Object". [/quote] I got this when trying it on a COM object that uses run-time generated type info (ie. CreateDispTypeInfo). This only provides a minimal implementation of ITypeInfo. This is not common(or recommended) so I wouldn't worry too much. If it helps the COM object is out of process. Also see this: http://groups.google.com/groups?q=typeName+%22Out+of+string+space%22

RE: The JScript Type System, Part Two: Prototypes and constructors

Eric Lippert — Sat, 08 Nov 2003 18:57:00 GMT

OK, then I have a guess as to what is happening. This is a TERRIBLE way to wait for an out-of-proc object (OOPO) to shut down. I'll bet that there is a race condition here where the stub is returning a pointer to memory that becomes bad when the OOPO shuts down. So the TypeName method essentially gets passed a pointer to bad memory. Now suppose that the bad memory happens to be in a readable committed page, but contains garbage. We assume that the thing is a BSTR, so we look at the value stashed preceding the string body to determine the length. That could be any old number; the odds that the number happens to be larger than the largest remaining heap block are actually very good. So what we've got here is a memory corruption bug that is not crashing, but returning a bogus error instead.

RE: The JScript Type System, Part Two: Prototypes and constructors

Anonymous — Sun, 09 Nov 2003 12:13:00 GMT

The link I posted was just something I found while searching on the error. My situation relates to using run time type info. Have you tested TypeName with run time type info? It is obsolete and I only use it for testing so this discussion is essentially accademic. My guess is that something similar is happening, ITypeInfo must be returning bogus data. Assuming that you check all error results this could even be a bug in the implementation of ITypeInfo for CreateDispTypeInfo. As mentioned, this is obsolete and probably hasn't been looked at for a long time. I think my object was based on the code found here, so if you want to copy and paste: http://docs.rinet.ru:8083/VidimyyC/vcu28fi.htm#I25

re: The JScript Type System, Part Two: Prototypes and constructors

Erik Arvidsson — Sun, 02 May 2004 14:07:00 GMT

"That's news to me. Could you more precisely define "around the corner"?"

I guess I was wrong :'( This has been in the works for way too long...

Known implemantions of ECMAScript v4:

ActionScript
QTScript
JScript 7

One possible reason for JS2 taking so long might be that ECMA moved all their resources to C# instead?

re: The JScript Type System, Part Two: Prototypes and constructors

Eric Lippert — Sun, 02 May 2004 15:23:00 GMT

A more likely reason is that Waldemar Horwat, who was the primary driving force behind the E4 spec, no longer works for AOL-Time-Warner-Netscape and hence is no longer being paid to drive the spec process forward. (Rumour has it that he's at google now.)

Microsoft is still involved in the E4 process, but it is slow going.

Wherefore IDispatchEx?

Fabulous Adventures In Coding — Thu, 07 Oct 2004 20:32:00 GMT

Intercept instanceof | keyongtech

Intercept instanceof | keyongtech — Sun, 18 Jan 2009 20:41:32 GMT

PingBack from http://www.keyongtech.com/4947719-intercept-instanceof