Distinguish between plain object types and class types

[aleclarson]

Search Terms

• plain object class type

Suggestion

Some way to distinguish an object type that only has Object in its prototype chain.

Use Cases

In this library, we use mapped types to convert immutable objects/arrays into their mutable representation. We never do this for class instances, so I need a way to skip the mapped type when an object type is actually a class type (in order to preserve readonly properties on class instances).

Examples

I have no suggestions for such syntax.

Checklist

My suggestion meets these guidelines:

• [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

Related

https://stackoverflow.com/questions/53819550/distinguish-between-plain-objects-and-class-types#53819550

[aleclarson]

Proposal A

Treat class Foo {} differently than class Foo extends Object {} like so:

• When extends Object is omitted from the class declaration, make Foo extends Object evaluate to false. Otherwise, behave normally.

Example

class Foo {
  private _: any
}
class Bar extends Object {
  private _: any
}

declare const test: (arg: Object) => void
test(new Foo) // 💥
test(new Bar) // 👍

declare const test2: (arg: object) => void
test2(new Foo) // 👍
test2(new Bar) // 👍

[aleclarson]

Proposal B

Add a new Exact<T> type that forbids narrow class types.

Details

• When T is a literal type, the resolved type is T
• When T is Object, any object literal is allowed (but Object sub-classes are not)
• When T is Array, any array literal is allowed (but Array sub-classes are not)
• When T is Function, any function literal is allowed (but Function sub-classes are not)
• When T is any other class, only instances of T are allowed (no sub-classes or super-classes)

Example

class Foo extends Object {
  constructor(public a: number) {}
}

declare const testObject: (arg: Exact<Object>) => void
testObject(new Foo(1)) // 💥
testObject({ a: 1 }) // 👍
testObject(Object.create(null)) // 👍

declare const testArray: (arg: Exact<Array>) => void
class MyArray extends Array {}
testArray(new MyArray()) // 💥
testArray([]) // 👍

declare const testFunc: (arg: Exact<Function>) => void
class MyFunc extends Function {}
testFunc(new MyFunc()) // 💥
testFunc(() => 0) // 👍

declare const testFoo: (arg: Exact<Foo>) => void
class Cart extends Foo {}
testFoo(new Foo(1)) // 👍
testFoo(new Cart(2)) // 💥

Related: #12936

[ctrlplusb]

@aleclarson - I'm facing the exact same issue in one of my libs. Please let me know if you figure any hacky workarounds. ❤️

[SephReed]

I have a proxy which should not ever be used for classes. I need a way to say: "This function can take objects, but not ones which are classes"

[SephReed]

Trying to solve this problem again, ended up back here.

[aleclarson]

@DanielRosenwasser @ahejlsberg Can this be brought up in a design meeting soon? 🤞

[AlexGalays]

I have a proxy which should not ever be used for classes. I need a way to say: "This function can take objects, but not ones which are classes"

I have exactly the same use case.

[SephReed]

@AlexGalays , depending on your project you can maybe do what I did:

1. add a property called _noProxy: true to every class you expect to be used
2. add a condition to your type which takes advantage of this

This is by no means perfect, but it can put out a few fires at least.

[AlexGalays]

@AlexGalays , depending on your project you can maybe do what I did:

1. add a property called _noProxy: true to every class you expect to be used
2. add a condition to your type which takes advantage of this

This is by no means perfect, but it can put out a few fires at least.

Yeah, unfortunately, I don't control all the class combinations, people can use their own :p

[SephReed]

Same with my project. They can use any class actually... so I have a long list of things which it should not proxy, and then am hoping to convince users within docs to add _noProxy: true to anything that messes them up. Once again, not great... but I would have had to give up on the project otherwise.

[juanrgm]

These examples are more fun.

https://www.typescriptlang.org/play?#code/MYewdgzgLgBAJGAhgWwKYC4YG8ZLZ6AJwEswBzGAXwG0BdGAXhmoCgZ3tcUMYAiKVNF5UANGw4AKAJSMAfJ0piOMAGYBXMMCjFwMaQqUdgAG0QQIMAMKnzB8ewBCIEMdSIwh9gHkARgCtULTFaAG4WFlBIWDhXcigAC0wcWLIEzDA1ZB9UQio6RmZ7ThS0mABGUSK6T2ZeQF4NwFI93loasFQAdxgAVVIoMoA2AEFCQkQATwkyqWCwoA

const $name: { name: string }[] = [
    { name: "test" },
    () => { },
    function () { },
    class Class { },
    Boolean,
    Object,
];

const $length: { length: number }[] = [
    { length: 1 },
    [],
    ["😥"],
    new Uint16Array(1),
];