Microsoft/TypeScript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

Bruce Pascoe

@fatcerberus

https://github.com/microsoft/TypeScript/issues/33475#issuecomment-532443362 - writing this up made me realize that classes should really always be nominally typed (even if there are no private properties) because of instanceof

obj instanceof B doesn't imply obj instanceof C at runtime

Guess that horse left the barn a long time ago though

Austin Cummings

@austincummings

@fatcerberus I thought the same thing when I was working on microsoft/TypeScript#32774.

Austin Cummings

@austincummings

...WRT nominal classes and instanceof

Shanon Jackson

@ShanonJackson

without providing any examples i feel like that would break interface same-name-as-class extension types

AnyhowStep

@AnyhowStep

One potential problem I might have with that narrowing is that it's possible to have A|B and then fail the A test and have it narrowed to B, even though it isn't B because it structurally matches A, just doesn't have the right prototype

@austincummings does your PR address that? =x

Like, if it fails the A constructor test, it shouldn't narrow in the false branch. Should still be of type A|B, imo

Because it looks like that test rules out the nominal side but not the structural side

Bruce Pascoe

@fatcerberus

Does instanceof behave that way now?

Because his test is basically just a different way to do an instanceof check

AnyhowStep

@AnyhowStep

class A {
  x! : number
}
class B {
  y! : number
}

//Neither A nor B, nominally
//Is A, structurally
const aOrB : A|B = { x : 32 };

if (aOrB instanceof A) {
  const a : A = aOrB; //OK
} else {
  const b : B = aOrB; //Expected to fail; is OK
}

Playground

Bruce Pascoe

@fatcerberus

So instanceof does narrow in the false branch

AnyhowStep

@AnyhowStep

I wonder if there's an issue

Asking to "fix" this

I could find anything

I used "instanceof narrow false branch"

Bruce Pascoe

@fatcerberus

Definitely think classes should have been all nominal all the time, but I'm realistic and realize that's not possible to change now

Plus it would differentiate class from interface typing-wise

AnyhowStep

@AnyhowStep

I guess I'll open an issue and wait for it to be closed as duplicate or working as intended lol

Bruce Pascoe

@fatcerberus

Haha

AnyhowStep

@AnyhowStep

microsoft/TypeScript#33481

AnyhowStep

@AnyhowStep

There are way too many ways to fetch a value from a database >.>

fetch-all-unmapped is the base "fetch" function and everything else is just a convenience function

AnyhowStep

@AnyhowStep

I haven't even worked on pagination and cursors yet

Shanon Jackson

@ShanonJackson

why not just...

import * from "./fetch"

fetch.mapped

fetch.unmapped

fetch.one

AnyhowStep

@AnyhowStep

I put every function in a separate file

Because each function can easily be hundreds of lines long. Not these ones. But I like consistency

Shanon Jackson

@ShanonJackson

i can see that

compose :)

AnyhowStep

@AnyhowStep

These functions aren't meant to be used externally

myQuery.fetchXxx()

Is how it would be exposed.

I have functional APIs internally but expose a fluent API for the most part for query building

Shanon Jackson

@ShanonJackson

fetch = {
mapped(...args: typeof fetch-mapped): ReturnType<typeof fetch-mapped> {
return mapped(...args); or whatever
}
}

ahh

Bruce Pascoe

@fatcerberus

@AnyhowStep Yeah so I knew the request for better instanceof behavior was going to be rejected for backward compat reasons but:

and it was an intentional decision to have a situation that wasn't 100% correct, but where usability outweighed.

I'm not sure I agree with the premise here. Structural typing of classes rarely makes sense in my experience; in almost all cases instanceof is my preferred method of narrowing with classes and that's 100% undeniably nominal

Unless they're interfaces, I pretty much never want class A to be considered the same type as class B just because they happen to have the same methods

Maybe I'm in the minority

There's also the thing that adding even one private property makes it nominal which is probably quite surprising if you haven't been told about it

AnyhowStep

@AnyhowStep

I agree and wish classes were always nominal and that, in my example, it would have been nice if the original assignment to aOrB was an error

AnyhowStep

@AnyhowStep

Ugh, I should just learn the TS code base so I can start making experimental PRs and running tests against their test suite

I'm really curious to see how much stuff breaks if I disallow object literal assignment to class types

Where communities thrive

People

Repo info

Activity