Get type of runtime value

Add .getType() to Object prototype, which will allow get real type of value in variable, just like C# do.

Proposed Changes

• Create const TypeSymbol = Symbol("tst-reflect-type");,
• for reflected classes generate Class[TypeSymbol] = getType<Class>()
• inruntime package declare

Object.defineProperty(Object.prototype, "getType", {
    enumerable: false,
    value: () => function() { return this.constructor[TypeSymbol]; }
});

Notes

Example

const foo: any = new Class();
foo.getType(); // => Type.ctor = Class

[Hookyns]

Done. Without extension of Object’s prototype.

@reflect() decorator needed just to say the transformer to include that type into metadata. It will not be needed after “include/exclude” configuration.

@reflect()
class A
{
}

@reflect()
class B
{
}

const a: any = new A();

const typeOfVarA = getType(a);
console.log(typeOfVarA.name); // > "A"

const typeOfA = getType<A>();
console.log(typeOfA.name, typeOfVarA.is(typeOfA), typeOfVarA == typeOfA); // > "A", true, true

const array: any = [new A(), new B()];

const typeOfArray = getType(array);
console.log(typeOfArray.isArray()); // > true

const arrayTypeArg = typeOfArray.getTypeArguments()[0];
console.log(arrayTypeArg.union); // > true
console.log(arrayTypeArg.types.map(arg => arg.name).join(", ")); // > "A, B"

const array2: any = [new A(), new B(), "string", true, false, { foo: "bar"}];

const typeOfArray2 = getType(array2);
console.log(typeOfArray2.isArray()); // > true

const arrayTypeArg2 = typeOfArray2.getTypeArguments()[0];
console.log(arrayTypeArg2.union); // > true
console.log(arrayTypeArg2.types.map(arg => arg.name).join(", ")); // > "A, B, string, boolean, Object"

console.log(arrayTypeArg2.types[4].getProperties().map(p => p.name + ":" + p.type.name)); // > [ "foo:string" ]

[rezonant]

A smaller point: Imagine there are two projects that do the same thing. Someone else (maybe making a serialization library or something) also decides to put getType() onto the Object prototype. What happens for users? Why is your getType() “more canonical” than someone else’s getType()? What if you want to use those two libraries together?

More importantly though, imagine your project becomes popular out on the web and then WHATWG decides to add a builtin getType() to Object, but they can’t because you modified the prototype and shipping that change in the browser will break all of these websites. This is literally what smooshgate was about (Mootools added Array.flatten, became popular, is now out there on websites that will never change, which forced the browser makers to go with Array.flat which is less than the ideal name for the method because Mootools decided they could just monkey patch any extra functionality they had directly onto the builtins). That’s what the article above is talking about- and it is a cautionary tale to framework designers in the ecosystem.

Monkeypatching methods onto built in types is short-sighted, will always be frowned upon, and has the real potential to cause problems for the ecosystem if your solution becomes popular. There’s so many other good options that bypass this entire problem too, it could be Type.getType(value) or getType(value) (as opposed to getType<T>()) or even getTypeFromValue(value).

I also have a lot of experience in C#, hell I’ve even implemented portions of the CLR in another life, it’s a great language and a great runtime. But what makes C# and the CLR great isn’t just that it has a convenient getType() method on the Object class.

It was bad practice because direct Object.prototype.getType change behavior of for…in, that’s why x.hasOwnProperty() should be used.

That’s a small (but important) detail at the time, but that is a very small reason compared to the larger reason of leaving the namespace on the builtin prototypes free for Ecmascript to define. You might ask, why don’t they just disable the ability to modify the builtin prototypes? That would preclude polyfills on already-standardized but not yet implemented features in the JS environment you are running in. It would also preclude Zone.js’ patching. And of course it would also break all the websites out there that already did it and that’s not really an option. But just because the option is there and the community has made this mistake before (again and again and again) does not mean we should walk carelessly into making that mistake yet again.

Here’s just a few references:

• “Inheritance and the prototype chain” (MDN) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain#Bad_practice_Extension_of_native_prototypes

  Warning: One misfeature that is often used is to extend Object.prototype or one of the other built-in prototypes.

  This technique is called monkey patching and breaks encapsulation. While used by popular frameworks such as Prototype.js, there is still no good reason for cluttering built-in types with additional non-standard functionality.

  The only good reason for extending a built-in prototype is to backport the features of newer JavaScript engines, like Array.forEach.

• “Why you should not modify a JavaScript object prototype” https://flaviocopes.com/javascript-why-not-modify-object-prototype/
• “Maintainable JavaScript: Don’t modify objects you don’t own” https://humanwhocodes.com/blog/2010/03/02/maintainable-javascript-dont-modify-objects-you-down-own/