Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:20
    sviat9440 closed #35553
  • 06:14
    sviat9440 edited #35553
  • 04:30
    typescript-bot opened #35564
  • 04:26
    agrozyme edited #35563
  • 04:20
    agrozyme opened #35563
  • 02:25
    alshdavid edited #35537
  • 02:24
    alshdavid edited #35537
  • 01:34
    amcasey closed #19533
  • 01:29
    minestarks edited #35559
  • 01:28
    minestarks edited #35559
  • 01:21
    weswigham edited #35561
  • 01:21
    weswigham edited #35561
  • 01:21
    weswigham edited #35561
  • 00:25
    loilo opened #35562
  • 00:25
    andrewbranch labeled #35019
  • 00:25
    andrewbranch labeled #35019
  • 00:23
    amcasey closed #21485
  • 00:22
    weswigham opened #35561
  • 00:21
    amcasey closed #35175
  • 00:18
    gdostie opened #35560
Bruce Pascoe
@fatcerberus
Destructuring in function parameter lists still confuses the hell out of me: microsoft/TypeScript#33474
I look at the signature and it's like... okay... now exactly what am I supposed to provide at the callsite for that
I have to mentally reconstruct the destructuring in order to know what to pass to it
AnyhowStep
@AnyhowStep
Fuck that mess lol
Bruce Pascoe
@fatcerberus
I don't see how using the nightly helps, nightlies don't include unmerged PR features do they?
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
}
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
AnyhowStep
@AnyhowStep
image.png
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