Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 4/22/2016 #8252

Closed
RyanCavanaugh opened this issue Apr 22, 2016 · 1 comment
Closed

Design Meeting Notes, 4/22/2016 #8252

RyanCavanaugh opened this issue Apr 22, 2016 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Apr 22, 2016

  • 6702 - readonly in .d.ts files

    • Problem: typescript@next users can't give their generated .d.ts files to 1.8 users
    • What's the difference between this and e.g. union types?
      • This one doesn't require any opting-in
      • Not universally true -- some expressions became union types, for example
    • Options
      • Commandline flag
      • Tool (regexp or something smarter)
      • Don't emit readonly in .d.ts until 2.0 ships, or "later"
      • Don't use typescript@next if your consumers aren't either
    • Who's encountering this?
      • tslint
      • Angular
        • Are they going to support pre-2.0 customers once 2.0 ships?
          • No
        • They only care about the window between the prerelease build and the real release
    • If we did it "later", how much later?
    • We'd like library authors to continue using bleeding-edge (good for us, good for them)
    • --sourceVersion or --dtsVersion ?
      • Very complex for marginal gain
    • Going forward, think about this scenario more explicitly
    • Conclusion: Use a regexp
  • 8191 - this in object literals

    • Breaks patterns people (Yehuda) use
    • In Ember.Object.extend, why doesn't init provide a contextual super type?
      • Works, but what about Object.assign ?
        • Well you're screwed
      • Could you even write the extend signature correctly?
      • No because you'd either get the base type or your own type, but not the & of them
    • 😕
    • Options
      • Go back to any, flag an error under --noImplicitThis
        • extend signature still impossible to write in an inferential way
      • Any other feedback on this yet?
        • Nope
      • Ryan remembers bugs wanting this but can't find them? Nathan found No referencing/intellisense fo nested properties/functions within class #7801
      • Some way for Ember.Object.extend to say to disable this behavior?
        • Contextual type with [s: string]: any signature
      • Add the object literal type to the contextual type when computing local this
    • Conclusion: See if it's possible to do this with contextual type + smarter this computation
  • 8124 - Typechecking of dependencies

    • Example scenario: You get a bundled .d.ts file written with implicit anys, then try to compile with --noImplicitAny
    • Interface reopening means errors might get reported in unexpected places
    • Why do we typecheck these at all?
      • Not doing it turned out poorly
      • We don't have the mechanics to report errors deterministically when not typechecking every file
      • Angular's doing it anyway
    • This issue is just about file-level suppression
      • What are the scenarios?
    • Rathole on error numbers
    • Our behavior in the presence of certain errors is not universally well-defined
    • Conclusion: Tactical fixes only
@RyanCavanaugh RyanCavanaugh added the Design Notes Notes from our design meetings label Apr 22, 2016
@DanielRosenwasser
Copy link
Member

Could you contextually type the argument to extend like so?

interface BoundMethod<T> {
    (this: T, ...args: any[]): any;
}

interface ObjectWithBoundMethods<T> {
    [propName: string]: BoundMethod<T> | {}
}

class MyObject {
    extend<T extends ObjectWithBoundMethods<T & this>>(other: T): T & this;
}

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants