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, 1/27/2017 #13729

Closed
DanielRosenwasser opened this issue Jan 27, 2017 · 1 comment
Closed

Design Meeting Notes, 1/27/2017 #13729

DanielRosenwasser opened this issue Jan 27, 2017 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Allow class to extend from generic type parameters (#4890)

Motivation: want to support mixin-like patterns

type Constructor = new (...args: any[]) => T;

class Base {
    constructor(public x: number, public y: number) {}
}

class Derived extends Base {
    constructor(x: number, y: number, public z: number) {
        super(x, y);
    }
}

function Tagged<T extends Constructor<Base>>(superClass: T) {
    return class extends superClass {
        _tag: string;
        constructor(...args: any[]) {
            super(...args);
            this._tag = "hello";
            this.x
        }
    }
}
  • Problems: substitutability is not guaranteed between the new type and a type parameter.

    • Something that is not necessary to address now.
  • Right now this is modeled with intersections.

    • When you intersect two types, TypeScript just recursively intersects members.
    • Problem: but right now signatures of intersection types are just sequentially concatenated togehter.
      • Example: the result of T & U & V has signatures of T followed by those of U followed by those of V.
    • Idea: what if whenever we see a (...args) => XXX signature, take other signatures and intersect the return type.
      • Example
        • T has a signature (x, y, z) => Derived
        • C has type: (...args: any[]) => C
        • T & C has type (x, y, z) => C & Derived
      • Question: What if ...args: string[]?
        • A: Restrict to any[]
      • Question: Does order matter?
        • A: Yes; (...args: any[]) => XXX only changes things if it's the latter type in the intersection.
      • Question: Can the latter type have multiple overloads in the type for this to take effect?
        • A: No.
      • Question: Should these types by swapped around?
        • Discussion
          • Probably less code uses (...args: any[]) => XXX as first overload.
          • Methods and constructor in derived class should have overloads that come first - more accurately models signatures.
        • A: Yes, they should.
  • Issues: what about generic constructors?

    • Can't model that well, but our thoughts are that we can eventually iterate.
  • Can we allow code that derives from any?

    • Conversation slips into call-site inference discussion.

Override keyword (#13217)

Current rules:

  • override is only allowed on class property declarations.
  • --noImplicitOverride method.
    • Errors if you override a method without override.
    • Includes augmentations.
  • Should you be able to override static members?
    • Unsure.
  • What about override abstract methods?
    • Why?
    • You want to substitute the signature, but acknowledge the override.
    • If so, why can't an interface have this?
    • Let's say no for now.
  • Resolution: let's take a look at the PR.

Expando object support

let x = {};

// add stuff to `x`

Another pattern:

var x = window.x || {}

Mainly for existing JavaScript patterns.

  • Problem: "gazillion" different ways of achieving this.

Out of time.

@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jan 27, 2017
@andy-hanson
Copy link

Re: override abstract
I think the decision was to allow to override an abstract method, but not with another abstract method. i.e.:

abstract class A {
	abstract m() {}
}

abstract class B extends A {
	// Error: cannot combine 'override' with 'abstract'
	override abstract m(x?: boolean) {}

	// OK
	abstract m(x?: boolean) {}
}

class C extends B {
	// Error: needs 'override' (assuming --noImplicitOverride)
	m(x?: boolean) {}

	// Error: signature mismatch
	m(x?: string) {}

	// OK
	override m(x?: boolean) {}
}

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
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