Typescript: 정적 멤버에 대한 다형성 "this"

내 보트의 크기와 모양은 매우 비슷합니다! 어이!

슈퍼클래스의 팩토리 메소드는 서브클래스의 새 인스턴스를 반환합니다. 내 코드의 기능은 작동하지만 반환 유형을 캐스팅해야 합니다.

class Parent {
    public static deserialize(data: Object): any { ... create new instance ... }
    // Can't return a this type from statics! ^^^ :(
}

class Child extends Parent { ... }

let data = { ... };
let aChild: Child = Child.deserialize(data);
//           ^^^ Requires a cast as type cannot be inferred.

나는 오늘도 이 문제에 부딪쳤다!

수정 솔루션은 자식 유형을 기본 클래스를 확장하는 제네릭으로 전달하는 것입니다. 이는 제가 당분간 적용하는 솔루션입니다.

class Parent {
    static create<T extends Parent>(): T {
        let t = new this();

        return <T>t;
    }
}

class Child extends Parent {
    field: string;
}

let b = Child.create<Child>();

이 문제가 닫힌 이유가 있습니까?

다형성이 정적에서 작동하지 않는다는 사실은 내 생각에 이 기능을 DOA로 만듭니다. 나는 지금까지 인스턴스 멤버에 대해 다형성이 실제로 필요하지 않았지만 정적 처리 시스템이 초기에 완성되었기 때문에 정적에 대해 몇 주마다 필요했습니다. 이 기능이 발표되었을 때 나는 매우 기뻤지만, 나중에 이 기능이 인스턴스 구성원에게만 작동한다는 사실을 알고는 실망했습니다.

사용 사례는 매우 기본적이고 매우 일반적입니다. 간단한 팩토리 메소드를 고려하십시오.

class Animal
{
    static create(): this
    {
        return new this();
    }
}

class Bunny extends Animal
{
    hop()
    {
    }
}

Bunny.create().hop() // Type error!! Come on!!

이 시점에서 저는 각 상속자에서 못생긴 캐스팅이나 static create() 메소드를 사용했습니다. 이 기능이 없으면 언어의 완성도가 상당히 떨어지는 것처럼 보입니다.

@paul-go 문제가 종료되지 않았습니다... ?

@paul-go 이 문제에도 좌절했지만 아래는 내가 찾은 가장 안정적인 해결 방법입니다. 각 Animal 하위 클래스는 super.create()를 호출하고 결과를 해당 유형으로 캐스팅해야 합니다. 별거 아니고 이것으로 쉽게 제거할 수 있는 원 라이너가 추가되었습니다.

컴파일러, 인텔리센스, 그리고 가장 중요한 토끼는 모두 만족합니다.

class Animal {
    public static create<T extends Animal>(): T {
        let TClass = this.constructor.prototype;
        return <T>( new TClass() );
    }
}

class Bunny extends Animal {    
    public static create(): Bunny {
        return <Bunny>super.create();
    }

    public hop(): void {
        console.log(" Hoppp!! :) ");
    }
}

Bunny.create().hop();

         \\
          \\_ " See? I am now a happy Bunny! "
           (')   " Don't be so hostile! "
          / )=           " :P "
        o( )_

@RyanCavanaugh 웁스 ... 어쩐지 이걸 #5862 와 혼동했네요 ... 전투도끼 공격 죄송합니다 :-)

@Think7 예 ... 따라서 "각 상속자에서 못생긴 캐스팅 또는 쓰레기 정적 create() 메서드에 정렬". 당신이 라이브러리 개발자이고 최종 사용자가 당신에게서 상속받은 클래스에서 많은 유형의 정적 메소드를 구현하도록 강제할 수는 없지만 꽤 어렵습니다.

라울. 코드 아래의 모든 것을 완전히 놓쳤습니다. D

그만한 가치가있었습니다. 토끼를 그려야합니다.

:+1: 토끼

:토끼: :하트:

+1, 꼭 보고 싶습니다.

이 주제에 대한 토론 업데이트가 있었습니까?

그것은 우리의 엄청난 제안 백로그에 남아 있습니다.

Javascript는 이미 이러한 패턴에서 올바르게 작동합니다. TS도 따를 수 있다면 많은 상용구/추가 코드에서 우리를 구할 수 있습니다. "모델 패턴"은 꽤 표준적인 패턴입니다. 저는 TS가 이에 대해 JS가 하는 것처럼 작동할 것으로 기대합니다.

나는 또한 다른 모든 사람들과 동일한 "CRUD 모델" 이유로 이 기능을 정말 원합니다. 인스턴스 메서드보다 정적 메서드에 필요합니다.

이것은 #8164에 설명된 문제에 대한 깔끔한 솔루션을 제공합니다.

재정의 및 제네릭이 포함된 "솔루션"이 있는 것은 좋지만 여기에서 실제로 해결하는 것은 없습니다. 이 기능을 사용하는 전체 목적은 이러한 재정의/캐스팅을 피하고 this 반환 방식과의 일관성을 만드는 것입니다. 유형은 인스턴스 메소드에서 처리됩니다.

저는 Sequelize 4.0에 대한 타이핑 작업을 하고 있으며 Model 클래스를 하위 클래스로 분류하는 접근 방식을 사용합니다. 해당 Model 클래스에는 findById() 등과 같은 수많은 정적 메서드가 있습니다. 물론 Model 를 반환하지 않지만 정적 컨텍스트에서 this 라는 하위 클래스를 반환합니다.

abstract class Model {
    public static tableName: string;
    public static findById(id: number): this { // error: a this type is only available in a non-static member of a class or interface 
        const rows = db.query(`SELECT * FROM ${this.tableName} WHERE id = ?`, [id]);
        const instance = new this();
        for (const column of Object.keys(rows[0])) {
            instance[column] = rows[0][column];
        }
        return instance;        
    }
}

class User extends Model {
    public static tableName = 'users';
    public username: string;    
}

const user = User.findById(1); // user instanceof User

현재 입력할 수 없습니다. Sequelize는 Node용 _the_ ORM이고 입력할 수 없다는 것이 아쉽습니다. 이 기능이 정말 필요합니다. 유일한 방법은 이러한 함수 중 하나를 호출할 때마다 캐스트하거나 모든 함수를 재정의하고 반환 유형을 조정하고 super.method() 호출만 하는 것입니다.

또한 정적 멤버는 제네릭 형식 인수를 참조할 수 없다는 것과 관련이 있습니다. 일부 메서드는 형식 인수를 통해 입력할 수 있는 모델에 대한 속성의 개체 리터럴을 사용하지만 인스턴스 멤버만 사용할 수 있습니다.

😰 이게 아직도 수정/추가가 안되었다는게 믿기지 않는다.....

우리는 이것을 잘 사용할 수 있습니다:

declare class NSObject {
    init(): this;
    static alloc(): this;
}

declare class UIButton extends NSObject {
}

let btn: UIButton = UIButton.alloc().init();

다음은 내가 작업했으면 하는 사용 사례입니다(https://github.com/Microsoft/TypeScript/issues/9775에서 마이그레이션했으며 이를 위해 마감했습니다).

현재 생성자의 매개변수는 this 유형을 사용할 수 없습니다.

class C<T> {
    constructor(
        public transformParam: (self: this) => T // not works
    ){
    }
    public transformMethod(self: this) : T { // works
        return undefined;
    }
}

예상됨: 생성자 매개변수에 사용할 수 있습니다.

해결하고자 하는 문제:

• 동일한 코드를 재사용하는 다른 유창한 API 주변에서 내 유창한 API를 기반으로 할 수 있습니다.

class TheirFluentApi {
    totallyUnrelated(): TheirFluentApi {
        return this;
    }
}

class MyFluentApi<FluentApi> {
    constructor(
        public toNextApi: (self: this) => FluentApi // let's imagine it works
    ){
    }
    one(): FluentApi {
        return this.toNextApi(this);
    }
    another(): FluentApi {
        return this.toNextApi(this);
    }
}

// self based fluent API;
const selfBased = new MyFluentApi(this => this);
selfBased.one().another();

// foreign based fluent API:
const foreignBased = new MyFluentApi(this => new TheirFluentApi());
foreignBased.one().totallyUnrelated();

미래 지향적인 해결 방법:

class Foo {

    foo() { }

    static create<T extends Foo>(): Foo & T {
        return new this() as Foo & T;
    }
}

class Bar extends Foo {

    bar() {}
}

class Baz extends Bar {

    baz() {}
}

Baz.create<Baz>().foo()
Baz.create<Baz>().bar()
Baz.create<Baz>().baz()

이렇게 하면 TypeScript가 정적 멤버에 대해 this 를 지원하면 새 사용자 코드는 Baz.create() 대신 Baz.create<Baz>() 가 되는 반면 이전 사용자 코드는 정상적으로 작동합니다. :웃다:

이것은 정말 필요합니다! 특히 인스턴스를 반환하는 정적 메서드가 있는 DAO의 경우. 대부분은 (저장, 가져오기, 업데이트 등...) 기본 DAO에 정의되어 있습니다.

정적 메소드의 this 유형이 클래스 유형이 아니라 해당 클래스로 해석되는(예: typeof ) 혼란을 일으킬 수 있다고 말할 수 있습니다.

실제 JS에서 유형에 대한 정적 메소드를 호출하면 함수 내부에서 this 가 클래스의 인스턴스가 아니라 클래스가 됩니다... 그래서 일관성이 없습니다.

그러나 사람들의 직관으로는 정적 메서드에서 this 반환 유형을 볼 때 가장 먼저 팝업되는 것이 인스턴스 유형이라고 생각합니다...

@shlomiassaf 일관성이 없습니다. User와 같은 함수의 반환 유형으로 클래스를 지정하면 반환 유형은 사용자의 인스턴스가 됩니다. 정확히 동일합니다. 정적 메서드에서 this의 반환 유형을 정의할 때 반환 유형은 this(클래스의 인스턴스)의 인스턴스가 됩니다. 클래스 자체를 반환하는 메서드는 typeof this로 모델링할 수 있습니다.

@felixfbecker 이것은 완전히 관점의 문제이며, 이것이 당신이 그것을 보는 방식을 선택하는 것입니다.

논리를 추론할 수 있도록 JS에서 어떤 일이 발생하는지 조사해 보겠습니다.

class Example {
  myFunc(): this {
    return this; 
  }

  static myFuncStatic(): this {
    return this;   // this === Example
  }
}

new Example().myFunc() //  instanceof Exapmle === true
Example.myFuncStatic() // === Example

이제 실제 런타임에서 this 는 함수의 제한된 컨텍스트입니다. 이것은 인터페이스와 같은 유창한 API에서 발생하는 일이며 다형성이 기능은 JS 작동 방식과 일치하는 올바른 유형을 반환하여 도움을 줍니다. this 를 반환하는 기본 클래스는 파생 클래스에서 생성한 인스턴스를 반환합니다. 이 기능은 실제로 수정 사항입니다.

요약하자면:
프로토타입(인스턴스)의 일부로 정의된 this 를 반환하는 메서드는 인스턴스를 반환해야 합니다.

계속해서 해당 논리를 사용하여 클래스 유형(프로토타입)의 일부로 정의된 this 를 반환하는 메서드는 클래스 유형인 경계 컨텍스트를 반환해야 합니다.

다시 말하지만, 편견도, 의견도, 단순한 사실도 없습니다.

직감적으로는 정적 함수에서 반환된 this 가 유형 내에 정의되어 있기 때문에 인스턴스를 나타내는 것이 편할 것입니다. 하지만 그게 전부입니다. 다른 사람들은 다르게 생각할 수 있고 우리는 그들의 잘못을 말할 수 없습니다.

문제는 클래스 인스턴스를 반환하는 정적 메서드와 클래스 자체(typeof this)를 반환하는 정적 메서드를 모두 입력할 수 있어야 한다는 것입니다. 귀하의 논리는 JS 관점에서 의미가 있지만 여기에서는 return _types_에 대해 이야기하고 있으며 TypeScript 및 기타 언어에서 클래스를 반환 유형(여기서는 this)으로 사용하는 것은 항상 클래스의 인스턴스를 의미합니다. 실제 클래스를 반환하기 위해 typeof 연산자가 있습니다.

@felixfbecker 이것은 또 다른 문제를 야기합니다!

this 유형이 인스턴스 유형인 경우 정적 메소드 본문에서 this 키워드가 참조하는 것과 다릅니다. return this 는 typeof this 의 함수 반환 유형을 생성합니다. 이는 완전히 이상합니다!

아니, 그렇지 않습니다. 다음과 같은 방법을 정의할 때

getUser(): User {
  ...
}

User 클래스가 아닌 User _instance_를 다시 받을 것으로 예상합니다(이것이 typeof 의 용도입니다). 모든 유형의 언어에서 작동하는 방식입니다. 유형 의미론은 단순히 런타임 의미론과 다릅니다.

this 또는 static 키워드를 func의 생성자로 사용하여 자식 클래스를 조작하지 않는 이유는 무엇입니까?

class Model {
  static find():this[] {
    return [new this("prop")]; // or new static(...)
  }
}

class Entity extends Model {
  constructor(public prop:string) {}
}

Entity.find().map(x => console.log(x.prop));

그리고 이것을 JS의 예와 비교하면 올바르게 작동하는 것을 볼 수 있습니다.

class Model {
  static find() { 
    return [new this] 
  }
}

class Entity extends Model {
  constructor(prop) {
    this.prop = prop;
  }
}

Entity.find().map(x => console.log(x.prop))

정적 메서드에 this 유형을 사용할 수 없습니다. 이것이 문제의 전체 루트라고 생각합니다.

@felixfbecker

이걸 고려하세요:

class Greeter {
    static getHandle(): this {
        return this;
    }
}

이 유형 주석은 직관적이지만 정적 메서드의 this 유형이 클래스 인스턴스인 경우 올바르지 않습니다. this 키워드는 정적 메서드에서 typeof this 유형을 가집니다!

나는 this 가 클래스 유형이 아니라 인스턴스 유형을 참조해야 한다고 생각합니다. 왜냐하면 우리는 인스턴스 유형( typeof X )에서 클래스 유형에 대한 참조를 얻을 수 있지만 그 반대의 경우는 불가능하기 때문입니다( instancetypeof X ?)

@xealot 좋아요, this static 키워드를 사용하지 않겠습니까? 그러나 JS 정적 컨텍스트의 this 는 여전히 생성자를 가리킵니다.

@izatop 예, 생성된 자바스크립트가 제대로 또는 부적절하게 작동합니다. 그러나 이것은 Javascript에 관한 것이 아닙니다. 불만은 Javascript 언어가 이 패턴을 허용하지 않는다는 것이 아니라 Typescript의 유형 시스템이 허용하지 않는다는 것입니다.

Typescript는 정적 멤버에 대한 다형성 this 유형을 허용하지 않기 때문에 이 패턴으로 유형 안전성을 유지할 수 없습니다. 여기에는 static 키워드와 constructor 로 정의된 클래스 메서드가 포함됩니다.

놀이터 링크

@LPGhatguy 근데 제 이전 댓글 잘 읽으셨죠?! 반환 유형이 User 인 메서드가 있는 경우 return User; 가 아니라 $ return new User(); 가 예상됩니다. 같은 방식으로 this 의 반환 값은 정적 메서드에서 return new this(); 를 의미해야 합니다. 비정적 메서드에서는 다르지만 this 는 항상 개체이므로 인스턴스화할 수 없습니다. 그러나 결국 우리는 기본적으로 이것이 typeof 때문에 이것이 최고의 구문이고 이 기능이 TS에서 많이 필요하다는 데 동의합니다.

@xealot TypeScript가 다형성 this 을 허용하지 않는 것을 이해하지만 이 기능을 TS에 추가하지 않는 이유를 묻겠습니다.

다음이 이 문제의 모든 사용 사례에 대해 작동하는지 모르겠지만 유형 추론 시스템의 현명한 사용과 함께 정적 메서드에서 this: 유형을 사용하면 타자. 믿을 수 없을 정도로 읽을 수는 없지만 자식 클래스에서 정적 메서드를 재정의하지 않고도 작업을 수행합니다.

[email protected] 에서 작동

다음을 고려하세요 ;

// IModelClass is just here to describe an instanciator
// since we can't use typeof T (unfortunately) with
// the generic type system.
interface IModelClass<T extends Model> {
  new (...a: any[]): T

  // unfortunately, we have to put here again all the typing information
  // of the static members (without static, since we are describing a class, not an instance)

  some_member: string
  create<T extends Model>(this: IModelClass<T>): T
}

class Model {

  // Here we use this with the IModel<T> to force the
  // type system to use T as our current caller.

  static some_member: string

  // When we call Dog.create() below, T is thus resolved
  // to Dog *and stays that way*
  // If typeof worked on generic types (it doesn't), we could have defined this method
  // instead as 
  // static create<T extends Model>(this: typeof T): T { ... }
  static create<T extends Model>(this: IModelClass<T>): T {
    return new this() // whatever you fancy here
  }
}

class Dog extends Model {
  bark() { }
}

class Cat extends Model {
  meow() { }
}

// Everything should be typed here, and we didn't have to redefine static methods
// in Dog nor Cat
let dog = Dog.create()
dog.bark()
let cat = Cat.create()
cat.meow()

@ceymard this 가 매개변수로 지정되는 이유는 무엇입니까?

이것은 함수에 대해 이 매개변수를 정의할 수 있는 typescript 2.0.0과 함께 제공되는 https://github.com/Microsoft/TypeScript/issues/3694 때문입니다 this 문제 및 기능의 잘못된 사용을 방지하기 위해)

정적 메서드뿐만 아니라 메서드에서도 사용할 수 있으며 우리가 제공하는 this 를 비교하도록 강제하여 유형 유추기를 "도움"하는 데 사용하는 것과 같이 정말 재미있는 것을 허용한다는 것이 밝혀졌습니다. (아이모델) 사용 중인 것(개 또는 고양이)으로 이동합니다. 그런 다음 T 에 대한 올바른 유형을 "추측"하고 이를 사용하므로 함수를 올바르게 입력합니다.

( this 는 typescript 컴파일러가 이해하는 _special_ 매개변수이며 함수에 하나를 더 추가하지 않습니다.)

구문이 <this extends Whatever> 와 같은 것이라고 생각했습니다. create() 에 다른 매개변수가 있는 경우에도 여전히 작동할까요?

전적으로

또한 이것이 내장 유형에 중요하다는 점을 지적하고 싶었습니다.
예를 들어 Array 를 하위 클래스로 지정하면 하위 클래스의 from() 메서드는 Array 가 아니라 하위 클래스의 인스턴스를 반환합니다.

class Task {}
class TaskList extends Array<Task> {
  public execute() {}
}
// actually returns instance of TaskList at runtime
const tasks = TaskList.from([new Task()])
tasks.execute() // error, method execute does not exist on type Array

이 문제에 대한 업데이트가 있습니까? 이 기능은 우리 팀의 TypeScript 경험을 크게 향상시킬 것입니다.

이것은 ORM에서 일반적으로 사용되는 패턴이고 많은 코드가 컴파일러 및 유형 시스템이 생각하는 것과 매우 다르게 동작하기 때문에 다소 중요합니다.

나는 반론에 반대하는 반론을 제기할 것입니다.

@shlomiassaf 가 지적했듯이 this 를 정적 멤버에 허용하면 this 가 정적 메서드와 인스턴스 메서드에서 다른 것을 의미하기 때문에 혼동을 일으킬 수 있습니다. 또한 유형 주석의 $# this this 는 의미가 다릅니다. 새 키워드를 도입하여 이러한 혼란을 피할 수 있지만 새 키워드의 비용은 높습니다.

그리고 현재 TypeScript에는 쉬운 해결 방법이 있습니다. @ceymard 는 이미 그것을 보여주었습니다 . 그리고 정적 메서드의 런타임 의미를 포착하기 때문에 그의 접근 방식을 선호합니다. 이 코드를 고려하십시오.

class A {
  constructor() {}
  static create<T extends A>(this: {new (): T}) {} // constructor signature is exactly the same as A's
}

class B extends A {
  constructor(a: number) {
    super()
  }
}

B.create() // correctly trigger compile error here

다형성이 지원되는 경우 컴파일러는 class B extends A 오류를 보고해야 합니다. 그러나 이것은 획기적인 변화입니다.

@HerringtonDarkholme 혼란이 보이지 않습니다 this 의 반환 유형은 정확히 return new this() 에서 기대하는 것입니다. 잠재적으로 이를 위해 self 를 사용할 수 있지만 다른 키워드(출력을 생성하는 데 사용된 키워드가 아닌)를 도입하는 것이 더 혼란스러워 보입니다. 우리는 이미 그것을 반환 유형으로 사용하고 있습니다. 유일한(그러나 큰) 문제는 정적 멤버에서 지원되지 않는다는 것입니다.

컴파일러는 프로그래머에게 해결 방법을 요구해서는 안 됩니다. TypeScript는 "향상된 JavaScript"여야 하며 이 경우에는 사실이 아닙니다. 수백만 개의 오류를 생성하지 않도록 코드에 대해 복잡한 해결 방법을 수행해야 합니다. 현재 버전에서 어떻게든 달성할 수 있다는 것은 좋지만 그렇다고 해서 문제가 없고 수정이 필요하지 않다는 의미는 아닙니다.

그렇다면 this 의 반환 유형이 메서드 본문의 this 유형과 다른 이유는 무엇입니까?
이 코드가 실패하는 이유는 무엇입니까? 새로운 사람에게 그것을 어떻게 설명할 수 있습니까?

class A {
  static create(): this {
     return this
  }
}

JavaScript의 상위 집합이 이것을 받아들이지 못하는 이유는 무엇입니까?

class A {
  static create() {
    return new this()
  }
}

abstract class B extends A {}

사실, 그러면 다른 키워드를 도입해야 할 수도 있습니다. self 또는 instance 수 있습니다.

@HerringtonDarkholme 초보자에게 설명하는 방법은 다음과 같습니다.
당신이 할 때

class A {
  static whatever(): B {
    return new B();
  }
}

B B 의 인스턴스를 반환해야 함을 의미합니다. 클래스 자체를 반환하려면 다음을 사용해야 합니다.

class B {
 static whatever(): typeof B {
   return B;
 }
}

이제 JavaScript에서와 마찬가지로 정적 멤버의 this 는 클래스를 참조합니다. 따라서 정적 메서드에서 this 의 반환 유형을 사용하는 경우 클래스의 인스턴스를 반환해야 합니다.

class A {
  static whatever(): this {
    return new this();
  }
}

클래스 자체를 반환하려면 typeof this 를 사용해야 합니다.

class A {
  static whatever(): typeof this {
    return this;
  }
}

그것이 바로 그 이후로 TS에서 유형이 이미 작동하는 방식입니다. 클래스로 입력하는 경우 TS는 인스턴스를 예상합니다. 클래스 유형 자체에 대해 입력하려면 typeof 를 사용해야 합니다.

그런 다음 this 가 메서드 본문에서 동일한 의미를 갖지 않는 이유를 묻겠습니다. 인스턴스 메소드 유형 주석의 this this 와 동일한 의미를 갖는 경우 정적 메소드와 동일하지 않은 이유는 무엇입니까?

우리는 딜레마에 직면해 있으며 세 가지 옵션이 있습니다.

1. make this 는 다른 컨텍스트에서 다른 것을 의미합니다(혼란).
2. self 또는 static 와 같은 새 키워드 도입
3. 프로그래머가 더 이상한 유형 주석을 작성하게 하십시오(일부 사용자에게 영향을 미침)

정적 메서드 정의의 런타임 의미를 반영하기 때문에 세 번째 접근 방식을 선호합니다.
또한 사이트를 정의하는 대신 사용 사이트에서 오류를 찾아냅니다. 즉, 이 주석 에서와 같이 오류는 class B extends A B.create 에서 보고됩니다. 이 경우 사용 사이트 오류가 더 정확합니다. ( this 를 참조하는 정적 메서드를 선언한 다음 추상 하위 클래스를 선언한다고 가정).

그리고 가장 중요한 것은 새로운 기능에 대한 언어 제안이 필요하지 않다는 것입니다.

실제로 선호도는 사람과 다릅니다. 하지만 적어도 이와 같은 보다 상세한 제안을 보고 싶습니다. 추상 클래스 할당 가능성, 하위 클래스 호환되지 않는 생성자 서명 및 오류 보고 전략과 같이 해결해야 할 문제가 많습니다.

@HerringtonDarkholme 인스턴스 메소드의 경우 런타임 this 는 클래스가 아닌 객체 인스턴스이기 때문에 혼동의 여지가 없습니다. this 유형은 말 그대로 런타임 this 이며 다른 옵션이 없습니다. 정적의 경우 객체 지향 프로그래밍 언어의 다른 클래스 주석처럼 작동하지만 클래스로 주석을 추가하면 인스턴스가 다시 돌아올 것으로 예상됩니다. 또한 TS의 경우 JavaScript 클래스도 객체이기 때문에 typeof 클래스로 입력하면 리터럴 클래스를 다시 얻을 수 있습니다.

내 말은, this 반환 유형을 구현했을 때 정적 케이스에 대해서도 생각하고 대신 사용자가 인스턴스 메소드에 대해 항상 typeof this 를 작성하도록 요구했을 때 아마도 더 일관성이 있었을 것입니다. 그러나 그 결정은 그 당시에 내려졌으므로 지금 작업해야 하며, 내가 말했듯이 인스턴스 메소드의 this 는 다른 유형을 생성하지 않기 때문에 혼동의 여지를 남기지 않습니다(클래스와 달리 정적 유형과 인스턴스 유형이 있음), 따라서 이 경우 구별되며 누구에게도 혼동을 주지 않습니다.

좋아요, 아무도 this 로 혼동하지 않을 것이라고 가정하겠습니다. 추상 클래스 할당 가능성은 어떻습니까?

메소드의 정적은 다소 임의적입니다. 모든 함수는 속성과 메서드를 가질 수 있습니다. new 로도 호출할 수 있는 경우 이러한 속성과 메서드를 static 로 호출하도록 선택합니다. 이제 이 규칙이 ECMAScript에 확고하게 자리 잡았습니다.

@HerringtonDarkholme this 를 사용하면 혼동을 일으킬 수 있다는 것은 의심의 여지가 없습니다. 그러나 this 를 사용하는 데 잘못된 것이 없기 때문에 특히 다양한 대안에 대한 당신의 기민한 비용 편익 분석을 고려할 때 완벽하게 괜찮다고 말하고 싶습니다. this 가 가장 나쁜 대안이라고 생각합니다.

나는 단지 내 원래 게시물에서 이 스레드를 따라잡으려고 노력했는데, 아마도 이것이 궤도에서 조금 벗어난 것 같은 느낌이 듭니다.

명확히 하자면 this 유형 주석이 생성자, 특히 일반/템플릿으로 사용될 때 다형성이 되기를 바라는 것입니다. @shlomiassaf 및 @HerringtonDarkholme 와 관련하여 저는 static 메서드가 있는 예제가 혼란스러울 수 있으며 이 문제의 의도가 아니라고 생각합니다.

자주 그렇게 생각되지는 않지만 클래스의 생성자는 정적입니다. 더 명확한 설명과 함께 다시 게시할 예제는 정적 메서드에서 this 를 선언하지 않고 대신 정적 메서드의 유형 주석에서 제네릭을 통해 나중에 사용할 수 있도록 this 를 선언합니다. .

차이점은 this 가 정적 메서드에서 즉시 계산되는 것을 원하지 않고 미래에는 동적 메서드에서 계산된다는 것입니다.

// START LIBRARY CODE
// Constrains the constructor to one that creates things that extend from BaseModel
interface ModelConstructor<T extends BaseModel> {
    new(fac: ModelAPI<T>): T;
}

class ModelAPI<T extends BaseModel> {
    // skipping the use of a ModelConstructor in favor of typeof does not work
    // constructor(private modelType: typeof T) {}
    constructor(private modelType: ModelConstructor<T>) {}

    create() {
        return new this.modelType(this);
    }
}

class BaseModel {
    // This is where "polymorphic `this`" in static members matters. We are 
    // trying to say that the ModelAPI should create instances of whatever 
    // the *current* class is, not the BaseModel class. Much like it would 
    // at runtime.
    constructor(private fac: ModelAPI<this>) {}

    reload() {
        // `reload()` returns a new instance of type Any, incorrect
        return this.fac.create();
    }
}
// END LIBRARY CODE

// START APPLICATION CODE
// Create a custom model class with custom behavior
class Model extends BaseModel {}

// Create an instance of the model API that produces my custom type
let api = new ModelAPI<Model>(Model);  // ModalAPI should be able to infer "<Model>" from the constructor?
let modelInst = api.create();  // Returns type of Model, correct
let reset = modelInst.reload();  // Returns type of Any, incorrect
// END APPLICATION CODE

이것이 혼란스럽다고 생각하는 사람에게는 글쎄요, 매우 간단하지 않다는 데 동의합니다. 그러나 BaseModel 의 생성자에서 this 를 사용하는 것은 실제로 정적 사용이 아니라 나중에 계산되는 지연 사용입니다. 그러나 정적 메서드(생성자 포함)는 그런 식으로 작동하지 않습니다.

런타임에 이 모든 것이 예상대로 작동한다고 생각합니다. 그러나 유형 시스템은 이 특정 패턴을 모델링할 수 없습니다. 이 문제가 공개된 이유는 typescript가 자바스크립트 패턴을 모델링할 수 없기 때문입니다.

급하게 작성한 댓글이 혼란스럽다면 죄송합니다.

@xealot 요점은 알지만 정적 메서드에 대한 다형성 this 을 구체적으로 제안한 다른 문제는 이 문제의 복제본으로 닫혔습니다. TS의 수정 사항이 두 사용 사례를 모두 활성화할 것이라고 가정합니다.

정확한 사용 사례는 무엇입니까? 아마도 '이것' 솔루션이면 충분할 것입니다.

나는 그것을 성공으로 사용자 정의 ORM 라이브러리에서 사용합니다.
르쥬. 10월 20일 2016 à 19:15, Tom Marius [email protected] a
에크리트 :

이것은 일반적으로 사용되기 때문에 다소 중요합니다.
ORM의 패턴과 많은 코드가
컴파일러와 유형 시스템은 그래야 한다고 생각합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/5863#issuecomment -255169194,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAtAoRHc45B386xdNhuCLB8iW6i82e7Uks5q16GzgaJpZM4GsmOH
.

@ceymard 와 @HerringtonDarkholme에게 감사드립니다.

static create<T extends A>(this: {new (): T}) { return new this(); } 가 나를 위해 속임수를 썼습니다 👍

언뜻 보기에는 static create(): this { return new this(); } 보다 더 모호하지만 적어도 맞습니다! 정적 메서드 내에서 this 유형을 정확하게 캡처합니다.

가장 많이 찬성되거나 댓글이 달리지 않더라도 이것이 어떻게든 우선 순위를 지정할 수 있기를 바랍니다. 예를 들어 올바른 유형을 얻기 위해 유형 인수를 사용해야 하는 것은 매우 성가신 일입니다.

let u = User.create<User>();

실제로 가능한 경우:

let u = User.create();

그리고 static이 때때로 인스턴스 유형을 참조하는 것은 불가피합니다.

정적 멤버의 this 유형이 클래스의 정적 측면 또는 인스턴스 측면의 유형이어야 하는지 여부에 대한 토론과 관련하여 또 다른 아이디어가 있었습니다. this 는 정적 측면이 될 수 있으며 인스턴스 멤버에서 수행되는 작업과 런타임 동작이 일치하면 this.prototype 를 통해 인스턴스 유형을 얻을 수 있습니다.

abstract class Model {
  static findAll(): Promise<this.prototype[]>
}

class User extends Model {}

const users: User[] = await User.findAll();

이것은 JavaScript에서 작동하는 방식과 일치합니다. this 는 클래스 개체 자체이고 인스턴스는 this.prototype 에 있습니다. this['prototype'] 에 해당하는 매핑된 유형과 본질적으로 동일한 메커니즘입니다.

같은 방식으로 this.constructor 를 통해 인스턴스 멤버에서 정적 측면을 사용할 수 있다고 상상할 수 있습니다(이 atm의 사용 사례는 생각할 수 없습니다).

또한 언급된 해결 방법/핵심 중 어느 것도 Sequelize에서 ORM 모델을 입력하는 데 작동하지 않는다는 점을 언급하고 싶었습니다.

• this 유형 주석은 생성자에서 사용할 수 없으므로 이 서명에서는 작동하지 않습니다.
  ts abstract class Model { constructor(values: Partial<this.prototype>) }
• 정적 멤버는 일반 매개 변수를 참조할 수 없으므로 형식을 일반 클래스 인수로 전달하면 정적 메서드에서 작동하지 않습니다.
• 형식을 일반 메서드 인수로 전달하면 메서드에서는 작동하지만 다음과 같은 정적 속성에서는 작동하지 않습니다.
  ts abstract class Model { static attributes: { [K in keyof this.prototype]: { type: DataType, field: string, unique: boolean, primaryKey: boolean, autoIncrement: boolean } }; }

이 요청에 대해 +1입니다. 내 ORM은 훨씬 깨끗합니다.

곧 깨끗한 솔루션을 볼 수 있기를 바랍니다.

한편, 솔루션을 제공한 모든 분들께 감사드립니다!

더 이상 논의가 없기 때문에 더 진행해도 될까요?

어디로 가져가시겠습니까? 이것은 내가 아는 한 Typescript가 Javascript를 깔끔하게 모델링할 수 없고 단순히 수행하지 않는 것 외에 해결 방법을 본 적이 없는 방식입니다.

이미 세 명의 인기 있는 ORM 소유자가 이 기능을 요청한 것을 볼 수 있으므로 이것은 ORM 개발자에게 필수 기능입니다.

@pleerock @xealot 솔루션은 위에서 제안되었습니다.

export type StaticThis<T> = { new (): T };

export class Base {
    static create<T extends Base>(this: StaticThis<T>) {
        const that = new this();
        return that;
    }
    baseMethod() { }
}

export class Derived extends Base {
    derivedMethod() { }
}

// works
Base.create().baseMethod();
Derived.create().baseMethod();
// works too
Derived.create().derivedMethod();
// does not work (normal)
Base.create().derivedMethod();

나는 이것을 광범위하게 사용하고 있습니다. 기본 클래스의 정적 메서드 선언은 약간 무겁지만 정적 메서드 내 this 유형의 왜곡을 피하기 위해 지불해야 하는 대가입니다.

@pleerock

this: 패턴을 문제 없이 광범위하게 사용하는 사내 ORM이 있습니다.

기능이 실제로 이미 여기에 있는 경우 언어를 과도하게 청구할 필요가 없다고 생각합니다. 보다 명확한 구문에 대한 사용 사례는 매우 제한적이며 불일치를 유발할 수 있습니다.

이 질문과 참조용 솔루션이 있는 Stackoverflow 스레드가 있을 수 있습니까?

@bjouhier @ceymard 이 스레드의 모든 해결 방법이 Sequelize에서 작동하지 않는 이유를 설명했습니다. https://github.com/Microsoft/TypeScript/issues/5863#issuecomment -269463313

그리고 이것은 ORM뿐만 아니라 표준 라이브러리에 관한 것입니다. https://github.com/Microsoft/TypeScript/issues/5863#issuecomment -244550725

@felixfbecker 방금 생성자 사용 사례에 대해 게시하고 삭제했습니다(게시 직후 TS가 모든 하위 클래스에서 생성자를 의무화하지 않는다는 것을 깨달았습니다).

@felixbecker 생성자의 경우 매개변수가 없는 생성자를 고수하고 대신 특수 정적 메서드(create, clone, ...)를 제공하여 해결합니다. 더 명확하고 입력하기 쉽습니다.

@bjouhier 즉, 기본적으로 모든 모델 하위 클래스에서 모든 단일 메서드를 다시 선언해야 합니다. Sequelize에 얼마나 많은지 보십시오: http://docs.sequelizejs.com/class/lib/model.js~Model.html

내 주장은 완전히 다른 관점에서 나온 것입니다. 부분적이고 다소 직관적이지 않은 해결 방법이 있으며 이것이 충분한지 여부에 대해 논쟁하고 동의하지 않을 수 있지만 이것이 Typescript가 Javascript를 쉽게 모델링할 수 없는 영역이라는 데 동의할 수 있습니다.

그리고 내 이해는 Typescript가 Javascript의 확장이어야 한다는 것입니다.

@felixfbecker

이는 기본적으로 모든 모델 하위 클래스에서 모든 단일 메서드를 다시 선언해야 함을 의미합니다.

왜요? 그것은 전혀 내 경험이 아닙니다. 코드 샘플로 문제를 설명할 수 있습니까?

@bjouhier 나는 이 스레드의 내 주석에 있는 코드 샘플로 문제를 심도 있게 설명했습니다. 시작을 위해 https://github.com/Microsoft/TypeScript/issues/5863#issuecomment -222348054

하지만 위의 create 예제를 보십시오. create 메서드는 정적 메서드입니다. 다시 선언되지 않았지만 하위 클래스에 제대로 입력되었습니다. 그렇다면 Model 의 메소드에 재정의가 필요한 이유는 무엇입니까?

@felixfbecker 귀하의 _시작을 위한_ 예:

export type StaticThis<T> = { new (): T };

abstract class Model {
    public static tableName: string;
    public static findById<T extends Model>(this: StaticThis<T>, id: number): T {
        const instance = new this();
        // details omitted
        return instance;        
    }
}

class User extends Model {
    public static tableName = 'users';
    public username: string;
}

const user = User.findById(1); 
console.log(user.username);

@bjouhier 좋아, this: { new (): T } 주석이 실제로 유형 추론이 작동하는 것처럼 보입니다. 이것이 컴파일러가 사용하는 기본 유형이 아닌 이유가 궁금합니다.
this 매개변수를 가질 수 없기 때문에 해결 방법은 물론 생성자에 대해 작동하지 않습니다.

예, 생성자에서는 작동하지 않지만 정적 create 메서드를 추가하여 작은 API 변경으로 문제를 해결할 수 있습니다.

이해하지만 이것은 JavaScript 라이브러리이므로 선언에 기존 API를 입력하는 것에 대해 이야기하고 있습니다.

this 가 정적 메서드 내에서 { new (): T } $를 의미한다면 this 는 정적 메서드 내에서 this 에 대한 올바른 유형이 아닙니다. 예를 들어 new this() 는 허용되지 않습니다. 일관성을 위해 this 는 클래스 인스턴스의 유형이 아니라 생성자 함수의 유형이어야 합니다.

기존 라이브러리를 입력하는 데 문제가 있습니다. 해당 라이브러리를 제어할 수 없는 경우 적절한 형식의 create 함수를 사용하여 중간 기본 클래스( BaseModel extends Model )를 만들고 BaseModel 에서 모든 모델을 파생시킬 수 있습니다.

기본 클래스의 정적 속성에 액세스하려면 다음을 사용할 수 있습니다.

public static findById<T extends Model>(this: (new () => T) & typeof Model, id: number): T {...}

그러나 아마도 생성자에 대한 유효한 요점이 있을 것입니다. 컴파일러가 다음을 거부해야 하는 어려운 이유를 찾지 못했습니다.

constructor(values: Partial<this>) {}

나는 여기에 고통이 있다는 @xealot 에 동의합니다. 우리가 쓸 수 있다면 너무 멋질 것입니다.

static findById(id: number): instanceof this { ... }

대신에

static findById<T extends Model>(this: (new () => T), id: number): T { ... }

그러나 우리는 타이핑 시스템에서 새로운 연산자가 필요합니다( instanceof ?). 다음은 유효하지 않습니다.

static findById(id: number): this { ... }

TS 2.4는 다음 해결 방법을 중단했습니다.
https://travis-ci.org/types/sequelize/builds/247636686

@sandersn @felixfbecker 나는 이것이 유효한 버그라고 생각합니다. 그러나 최소한의 방식으로는 재현할 수 없습니다. 콜백 매개변수는 반공변입니다.

// Hooks
User.afterFind((users: User[], options: FindOptions) => {
  console.log('found');
});

이 문제가 언젠가는 해결될 가능성이 있습니까?

나는 오늘도 이것에 부딪쳤다. 기본적으로 다음과 같이 싱글톤 기본 클래스를 만들고 싶었습니다.

abstract class Singleton<T> {
  private static _instance?: T

  public static function getInstance (): T {
    return this._instance || (this._instance = new T())
  }
}

사용법은 다음과 같습니다.

class Foo extends Singleton<Foo> {
  bar () {
    console.log('baz!')
  }
}

Foo.getInstance().bar() // baz!

위에서 언급한 StaticThis 변형과 다른 많은 변형을 포함하여 이것의 약 10가지 변형을 시도했습니다. 결국 컴파일되는 버전은 하나뿐이지만 getInstance() 의 결과는 getInstance() Object 파생되었습니다.

나는 이것이 이러한 구성으로 작업하는 것보다 훨씬 어렵다고 생각합니다.

다음 작품:

class Singleton {
    private static _instance?: Singleton;

    static getInstance<T extends Singleton>(this: { new(): T }) {
      const constr = this as any as typeof Singleton; // hack
      return (constr._instance || (constr._instance = new this())) as T;
    }
  }

  class Foo extends Singleton {
    foo () { console.log('foo!'); }
  }

  class Bar extends Singleton {
    bar () { console.log('bar!');}
  }

  Foo.getInstance().foo();
  Bar.getInstance().bar();

this as any as typeof Singleton 부분은 보기 흉하지만 _instance 가 파생 클래스의 생성자에 저장되어야 하므로 유형 시스템을 속이고 있음을 나타냅니다.

일반적으로 기본 클래스는 프레임워크에 묻히므로 구현이 약간 못생긴 경우에도 크게 해를 끼치지 않습니다. 중요한 것은 파생 클래스의 깨끗한 코드입니다.

2.8 nightlies에서 다음과 같이 할 수 있기를 바랐습니다.

static findById(id: number): InstanceType<this> { ... }

슬프게도 그런 행운은 없습니다 :(

@bjouhier 코드 예제는 매력처럼 작동합니다. 그러나 IntelliSense 자동 완성을 중단합니다.

React 16.3.0이 출시되었으며 정적 메소드가 클래스 유형 매개변수를 참조할 수 없는 경우 새로운 getDerivedStateFromProps 메소드를 올바르게 입력하는 것이 불가능해 보입니다.

(단순한 예)

class Component<P, S> {

    static getDerivedStateFromProps?<K extends keyof S>(nextProps: P, prevState: S): Pick<S, K> | null

    props: P
    state: S
}

해결 방법이 있습니까? (나는 "P와 S를 PP와 SS로 입력하고 개발자들이 이 두 유형 패밀리를 정확하게 일치시키길 바랍니다"를 하나로 계산하지 않습니다.)

홍보: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/24577

@cncolder 나도 Intellisense의 파괴를 목격했습니다. 나는 그것이 typescript 2.7에서 시작되었다고 믿습니다.

여기에서 볼 수 없는 한 가지는 Singleton 예제를 확장하는 것입니다. Singleton / Multiton 클래스에 보호된 생성자를 만드는 것이 일반적인 패턴입니다. 그리고 유형이 { new(): T } 인 경우 확장할 수 없습니다. 공개 생성자를 적용합니다 - this 용어 또는 여기에 제공된 다른 솔루션( instanceof this , typeof this 등)이 해당 문제를 해결해야 합니다. 이것은 싱글톤이 생성 등을 요청하지 않은 경우 생성자에서 오류를 던지면 확실히 가능합니다. 그러나 이는 오류 입력의 목적을 무효화합니다 - 런타임 솔루션을 갖기 위해...

class Singleton {

  private static _instance?: Singleton;

  public static getInstance<T extends Singleton> ( this: { new(): T } ): T {
    const ctor: typeof Singleton = this as any; // hack
    return (ctor._instance || (ctor._instance = new this())) as T;
  }

  protected constructor ( ) { return; } 
}

class A extends Singleton {
  protected constructor ( ) {
    super();
  }
}

A.getInstance() // fails because constructor is not public

getInstance() 가 있는 TS에서 싱글톤이 필요한 이유를 모르겠습니다. 개체 리터럴을 정의하면 됩니다. 또는 절대적으로 클래스를 사용하려는 경우(비공개 멤버의 경우) 클래스 인스턴스만 내보내고 클래스는 내보내지 않거나 클래스 표현식( export new class ... )을 사용합니다.

이것은 Multiton에 더 유용합니다. 그리고 저는 작동하는 패턴을 발견했다고 믿습니다. 비록 이 유형이 없으면 여전히 매우 해키한 느낌이지만.. 대신 이것은 필요합니다.

this -> { new(): T } & typeof Multiton | Function

class Multiton {
  private static _instances?: { [key: string]: any };

  public static getInstance<T extends Multiton> (
    this: { new(): T } & typeof Multiton | Function, key: string
  ): T {
    const instances: { [key: string]: T } =
      (this as typeof Multiton)._instances ||
     ((this as typeof Multiton)._instances = { });

    return (instances[key] ||
      (instances[key] = new (this as typeof Multiton)() as T)
    );
  }

  protected constructor ( ) { return; }
}

class A extends Multiton {
  public getA ( ): void { return; }
}
A.getInstance("some-key").getA();
assert(A.getInstance("some-key") === A.getInstance("some-key"))
new A(); // type error, protected constructor

또한 생성 시 자식 클래스에서 액세스할 수 있도록 키를 저장하는 코드가 있지만 단순성을 위해 제거했습니다...

안녕. 생성자에 대해 다형성 "this"가 필요한 문제가 발생했습니다. 이 댓글과 비슷합니다.

수업을 만들고 싶습니다. 클래스 자체에는 많은 속성이 있으므로 해당 클래스의 모든 속성이 생성자의 매개변수를 통해 초기화되면 생성자가 보기에 좋지 않습니다.

속성을 초기화하기 위해 개체를 허용하는 생성자를 선호합니다. 예를 들어:

class Vehicle {
  // many properties here
  // ...

  constructor(value: Partial<Vehicle>) {
      Object.assign(this, value)
  }
}

let vehicle = new Vehicle({
  // <-- IntelliSense works here
})

그런 다음 수업을 연장하고 싶습니다. 예를 들어:

class Car extends Vehicle {
  // more properties here
  // ...
}

let car = new Car({
  // <-- I can't infer Car's properties here
})

this 유형을 생성자에서도 사용할 수 있다면 매우 좋을 것입니다.

class Vehicle {
  // ...
  constructor(value: Partial<this>) {
      // ...

따라서 IntelliSense는 추가 상용구 없이 자식 클래스의 속성을 유추할 수 있습니다(예: 생성자 재정의). 클래스 초기화를 위해 정적 메서드를 사용하는 것보다 더 자연스럽게 보일 것입니다.

let car = new Car({
  // <-- Car's properties will be able to be inferred if Partial<this> is allowed
})

고려해주셔서 대단히 감사합니다.

이 스레드를 발견하게 되어 기쁩니다. 나는 솔직히 이것이 매우 심각한 문제라고 생각하며 3.0까지 이어지는 것을 보고 매우 낙담했습니다.

모든 솔루션을 살펴보고 지난 몇 년 동안 수행한 다양한 해결 방법을 고려하면 솔루션이 준비되어 있으면 빠른 수정 이 실패할 것이라는 결론에 도달했습니다. 그때까지 우리가 하는 모든 강제는 프로젝트 전체에서 유지하기 위해 너무 많은 수작업을 필요로 합니다. 그리고 일단 게시되면 소비자가 자신의 사고 방식을 이해하고 TypeScript를 수정하기로 선택한 이유를 소비자가 단순히 바닐라로 패키지를 소비하지만 우리 대부분과 마찬가지로 VSCode를 사용하는 경우에 이해할 수 없습니다.

동시에 실제 언어가 문제가 아닐 때 Type System을 만족스럽게 만드는 코드를 작성하는 것은 Typed 기능을 사용하는 것과 동일한 이유로 시작됩니다.

모든 사람에게 내가 추천하는 것은 구불구불한 모양이 잘못 되었다는 것을 받아들이고 가능한 경우 //@ts-ignore because my code works as expected 를 사용하는 것입니다.

당신의 린터가 합리적인 인간 지능에 면역이 있다면, 그 자리를 알고 있는 린터를 찾아야 할 때입니다.

업데이트 :
정적 추론 을 안전하게 강화하기 위해 내 자신의 시도를 추가하고 싶었습니다. 이 접근 방식은 방해가 되지 않도록 하기 위해 엄격하게 주변적입니다. 상속이 당신을 위해 일할 것이라고 가정하지 않고 당신의 증강을 확인하도록 강요하는 것은 철저하게 명시적입니다.

export class Sequence<T> {
  static from(...values) {
    // … returns Sequence<T>
  };
}

export class Peekable<T> extends Sequence<T> {
  // no augmentations needed in actual class body
}

/// AMBIENT /// Usually keep those at the bottom of my files

export declare namespace Peekable {
  export function from<T>(... values: T[]): Peekable<T>;
}

분명히 이 패턴이 유지되거나 이 스레드의 모든 시나리오를 충족한다고 보장할 수 없지만 현재로서는 예상대로 작동합니다.

세이프어레이

/**
 * Represents an Automation SAFEARRAY
 */
declare class SafeArray<T = any> {
    private constructor();
    private SafeArray_typekey: SafeArray<T>;
}

변수 날짜

/**
 * Automation date (VT_DATE)
 */
declare class VarDate {
    private constructor();
    private VarDate_typekey: VarDate;
}

오늘은 잠시 토론했습니다. 키 포인트:

• this 는 인스턴스 쪽을 참조합니까 아니면 정적 쪽을 참조합니까?
  
  
  
  • 확실히 정적 측면. 인스턴스 쪽은 InstanceTypeOf 를 통해 참조할 수 있지만 그 반대는 사실이 아닙니다. 이것은 또한 서명의 this this 와 동일한 유형을 갖도록 대칭을 유지합니다.
  
  
• 건전성 문제
  
  
  
  • 파생 클래스 생성자 매개변수 목록이 기본 클래스 생성자 매개변수 목록과 관련이 있다는 보장은 없습니다.
  
  
  • 클래스는 이와 관련하여 매우 자주 정적 측 대체 가능성을 깨뜨립니다.
  
  
  • 비구성측 대체 가능성 이 시행되며 이것은 일반적으로 사람들이 어쨌든 관심을 갖는 것입니다.
  
  
  • 우리는 이미 static new this() 의 불건전한 호출을 허용합니다.
  
  
  • 아무도 외부에서 정적 this 의 구성 서명 측면에 대해 신경 쓰지 않을 것입니까?
  
  

기존 해결 방법:

class Foo {
    static boo<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();

특히 이것은 Bar 의 구성 서명이 Foo 를 적절히 대체할 수 있는 경우에만 작동합니다.

@RyanCavanaugh this 에 대한 값이 귀하의 예제 static boo<T extends typeof Foo>(this: T): InstanceType<T> 에서 유래한 설명을 제시하려고 했지만 이해가 되지 않습니다. 제네릭에 대한 모든 것을 다시 읽었지만 여전히 - 아니요. 예를 들어 this 를 clazz 로 바꾸면 더 이상 작동하지 않고 컴파일러는 "인수 1개를 예상했지만 0을 얻었습니다."라고 불평합니다. 그래서 마법이 일어나고 있습니다. 설명해 주시겠습니까? 아니면 문서의 올바른 방향을 알려주시겠습니까?

편집하다:
또한 단순히 extends Foo 가 아닌 extends typeof Foo 인 이유는 무엇입니까?

@creynders this 는 함수의 컨텍스트에 대해 입력할 수 있는 특수한 가짜 매개변수입니다. 문서 .

제네릭이 관련된 경우 InstanceType<T> 를 사용하면 작동하지 않습니다.

내 사용 사례는 다음과 같습니다.

const _data = Symbol('data');

class ModelBase<T> {
    [_data]: Readonly<T>;

    protected constructor(data: T) {
        this[_data] = Object.freeze(data);
    }


    static create<T, V extends typeof ModelBase>(this: V, data : T): InstanceType<V> {
        return new this(data);
    }
}

interface IUserData {
    id: number;
}

class User extends ModelBase<IUserData> {}

User.create({ id: 5 });

TypeScript 플레이그라운드 링크

@mastermatt 오 와우, 문서를 읽을 때 완전히 선택하지 않았습니다... 감사합니다.

@RyanCavanaugh 의 예를 보면 정적 메서드가 작동하도록 할 수 있었지만 정적 메서드를 참조하는 인스턴스 메서드도 있지만 올바른 입력 방법을 알 수 없습니다.

예시:

class Foo {
    static boo<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }

    boo<T extends typeof Foo>(this: InstanceType<T>): InstanceType<T> {
      return (this.constructor as T).boo();
    }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();
// c: Foo
let c = b.boo();

이 마지막 문제에 대한 해결 방법을 찾을 수 있다면 공식적인 무언가가 나올 때까지 설정하겠습니다.

또한 해당 예에서 하위 클래스가 정적 메서드를 재정의한 다음 super 를 호출하려고 하면 모두 화가 납니다... 이 두 가지 문제 외에 해결 방법은 제대로 작동하는 것 같습니다. 하지만 이 두 가지 문제가 우리 코드를 차단하고 있습니다.

IIRC 이것은 타입 시스템을 약간 구부리지 않고는 타이프스크립트로 표현할 수 없기 때문입니다. 에서와 같이 ; this.constructor는 당신이 생각하는 것이나 그와 비슷한 것이 전혀 보장되지 않습니다.

이 정확한 경우에는 boo() 인스턴스 메서드가 this 를 반환하고 내부에서 약간의 속임수를 사용하여 컴파일러가 내가 무엇을 하고 있는지 알고 있음을 인정하도록 합니다.

내 일반적인 추론은 때때로 약간의 속임수를 의미하더라도 나머지 코드에 대해 API가 가능한 한 단순하기를 원한다는 것입니다.

누군가 더 강력한 것을 가지고 있다면 나는 그것을 좋아할 것입니다.

class Foo {
  static boo<T extends typeof Foo>(this: T): InstanceType<T> {
      return (new this()) as InstanceType<T>;
  }

  boo(): this {
    // @ts-ignore : wow this is ugly 
    return (this.constructor).boo();
  }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();
// c: Bar !
let c = b.boo();

인터페이스 경로로 이동하여 이와 같은 작업을 수행할 수도 있습니다.

interface FooMaker<T> {
  new(...a: any[]): T
  boo(): T
}


class Foo {
  static boo<T extends typeof Foo>(this: T): InstanceType<T> {
      return (new this()) as InstanceType<T>;
  }

  boo(): this {
    return (this.constructor as FooMaker<this>).boo();
  }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();
// c: Bar !
let c = b.boo();

이것도 부정 행위이지만 조금 더 통제가 가능합니까? 정말 말할 수 없습니다.

그래서 정적 "boo" 메소드의 첫 번째, this 인수는 일반 인수가 아닌 특별히 처리됩니까? 이것을 설명하는 문서에 대한 링크가 있습니까?

class Foo {
    static boo<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }
}

class Bar extends Foo {
}

// b: Bar
let b = Bar.boo();

나는 같은 (적어도 비슷한) 문제가 있습니다.
저는 JSDoc(TypeScript가 아님)와 함께 Vanilla Javascript를 사용하고 있으므로 이 스레드에서 제안된 제네릭을 중심으로 회전하는 해결 방법을 사용/구현할 수 없지만 루트는 동일한 것 같습니다.
이 문제를 열었습니다. #28880

이 문제는 말 그대로 이미 3년이 지났습니다.
나에게 맞는 적절한 해결 방법을 찾은 사람이 있습니까?

삼 년

@RyanCavanaugh 의 해결 방법은 정적 메서드에 적합하지만 정적 접근자는 어떻습니까?

class Factory<T> {
  get(): T { ... }
}

class Base {
  static factory<T extends Base>(this: Constructor<T>): Factory<T> {
    //
  }

  // what about a getter?
  static get factory<** no generics allowed for accessors **> ...
}

삼 년

좋아, 당신은 날짜를 빼는 데 절반 정도는 괜찮습니다. 하지만 해결책을 제시할 수 있습니까? ;)

@RyanCavanaugh 이것은 다음과 같이 제너레이터에서 this 값을 사용할 때 문제입니다.

class C {
  constructor(f: (this: this) => void) {
  }
}
new C(function* () {
  this;
  yield;
});

생성기를 만들 때 화살표 함수를 사용하여 this 값을 사용할 수 없습니다. 이제 우리는 서브클래스에서 명시적으로 this 유형을 선언해야 합니다. 실제 사례는 다음과 같습니다.

      class Component extends Coroutine<void> implements El {
        constructor() {
          super(function* (this: Component) {
            while (true) {
              yield;
            }
          }, { size: Infinity });
        }
        private readonly dom = Shadow.section({
          style: HTML.style(`ul { width: 100px; }`),
          content: HTML.ul([
            HTML.li(`item`)
          ] as const),
        });
        public readonly element = this.dom.element;
        public get children() {
          return this.dom.children.content.children;
        }
        public set children(children) {
          this.dom.children.content.children = children;
        }
      }

https://github.com/falsandtru/typed-dom/blob/v0.0.134/test/integration/package.ts#L469

기본 클래스에서 할 수 있다면 서브클래스에서 this 유형을 선언할 필요가 없습니다. 단, 슈퍼 클래스에서 제너레이터가 동기적으로 호출될 때 this 값은 초기화되지 않는다. 코드에서 이 문제를 피했지만 이것은 더러운 해킹입니다. 따라서 이 패턴은 원래 클래스 기반 프로그래밍 언어와 일치하지 않을 수 있습니다.

가장 깨끗하지는 않지만 정적 메서드에서 자식 클래스에 액세스하는 데 유용할 수 있습니다.

class Base {
    static foo<T extends typeof Base>() {
        let ctr = Object.create(this.prototype as InstanceType<T>).constructor;
        // ...
    }
}

class C extends Base {
}

C.foo();

현재 제가 겪고 있는 문제가 이것 때문인지는 모르겠지만 이 문제를 간단히 살펴보면 아마도 그럴 것 같습니다. 그렇지 않은 경우 수정하십시오.

그래서 상속을 통해 관련된 다음 2개의 클래스가 있습니다.

export class Target {
  public static create<T extends Target = Target>(that: Partial<T>): T {
    const obj: T = Object.create(this.prototype);
    this.mapObject(obj, that);
    return obj;
  }
  public static mapObject<T extends Target = Target>(obj: T, that: Partial<T>) {
    // works with "strictNullChecks": false
    obj.prop1 = that.prop1;
    obj.prop2 = that.prop2;
  }

  public prop1!: string;
  constructor(public prop2: string) {}
}

export class SubTarget extends Target {
  public subProp!: string;
}

다음으로 SubTarget 클래스에 mapObject 메소드를 다음과 같이 추가합니다.

  public static mapObject(obj: SubTarget, that: Partial<SubTarget>) {
    super.mapObject(obj, that);
    obj.subProp = that.subProp;
  }

이것이 작동할 것으로 예상했지만 다음 오류가 발생합니다.

Class static side 'typeof SubTarget' incorrectly extends base class static side 'typeof Target'.
  Types of property 'mapObject' are incompatible.
    Type '(obj: SubTarget, that: Partial<SubTarget>) => void' is not assignable to type '<T extends Target>(obj: T, that: Partial<T>) => void'.
      Types of parameters 'obj' and 'obj' are incompatible.
        Type 'T' is not assignable to type 'SubTarget'.
          Property 'subProp' is missing in type 'Target' but required in type 'SubTarget'.

이 문제로 인해 이 오류가 발생합니까? 그렇지 않으면 설명이 정말 좋을 것입니다.

놀이터 바로가기

호출되는 실제 클래스의 새 인스턴스를 반환하는 정적 메서드에 주석을 달기 위한 솔루션을 찾는 동안 여기에 왔습니다.

@SMotaal 이 제안한 해결 방법( new this() 와 함께 사용)이 가장 깨끗하고 나에게 가장 합리적이라고 생각합니다. 원하는 의도를 표현할 수 있고 제네릭 메서드를 호출할 때마다 유형을 지정하지 않아도 되며 최종 코드에 오버헤드가 추가되지 않습니다.

그러나 진지하게 이것이 아직 핵심 Typescript의 일부가 아닌 이유는 무엇입니까? 상당히 일반적인 시나리오입니다.

@danielvy — OOP와 프로토타입 사이의 단절이 모두를 행복하게 하지 못하는 더 큰 정신적 격차라고 생각합니다. 내 생각에 클래스에 대한 핵심 가정은 사양에서 진화한 클래스 기능이 정렬되지 않았고, 이를 깨는 것은 많은 TypeScript 기능에 대한 함정이므로 모든 사람이 "우선 순위를 지정"하고 있으며 괜찮지만 " 유형"이라고 생각합니다. 경쟁 제품보다 더 나은 솔루션이 없는 것은 경쟁이 있는 경우에만 문제입니다. 이것이 순전히 한 바구니에 담긴 모든 계란이 항상 모두에게 나쁜 이유입니다. 저는 실용적이고 성실합니다.

이것은 작동하지 않습니다:

export class Base {
  static getEntitySchema<T extends typeof Base>(
    this: T,
  ): InstanceType<T> {
  }
}

export class Extension extends Base {
  static member: string = '';
  static getEntitySchema<T extends typeof Extension>(
    this: T,
  ): InstanceType<T> {
  }
}

Type 'typeof Base' is missing the following properties from type 'typeof Extension ': member.

그러나 Extension이 Base를 확장하므로 이것이 허용되어서는 안됩니까?

이것이 작동한다는 점에 유의하십시오.

export class Extension extends Base {
  static member: string = '';
  static getEntitySchema<T extends typeof Base>(
    this: T,
  ): InstanceType<T> {
  }
}

하지만 그 안에 this.member를 사용할 수 없습니다.

그래서 @ntucker 게시물에서 확장 클래스가 기본 클래스와 정확히 일치하지 않는 한 해결 방법은 한 수준 깊이에서만 작동한다고 추측하고 있습니다.

여보세요! 보호된 생성자는 어떻습니까?

class A {
  static create<T extends A>(
    this: {new(): T}
  ) {
    return new this();
  }

  protected constructor() {}
}

class B extends A {} 

B.create(); // Error ts(2684)

생성자가 public 이면 괜찮지만 그렇지 않으면 오류가 발생합니다.

The 'this' context of type 'typeof B' is not assignable to method's 'this' of type '(new () => B) & typeof A'.
  Type 'typeof B' is not assignable to type 'new () => B'.
    Cannot assign a 'protected' constructor type to a 'public' constructor type.

놀이터 - http://tiny.cc/r74c9y

이에 대한 희망이 있습니까? 이 필요를 다시 한 번 우연히 발견했습니다 :F

@ntucker Duuuuudee 수고하셨습니다!!! 저에게 중요한 깨달음은 this 매개변수를 선언하고 마지막에 InstanceType<U> 캐스트를 수행하여 정적 create 메소드를 일반화하는 것이었습니다.

운동장

위에서 ^

class Base<T> {
  public static create<U extends typeof Base>(
    this: U
  ) {
    return new this() as InstanceType<U>
  }
}

class Derived extends Base<Derived> {}
const d: Derived = Derived.create() // works 😄 

이것은 내 사용 사례를 완벽하게 충족시키며 TS 3.5.1 현재 이 스레드의 ppl 대부분을 만족시키는 것 같습니다(정적 소품 theAnswer 및 3단계 확장 탐색을 위한 놀이터 참조)

핫 테이크: 이것이 지금 작동하고 닫을 수 있다고 생각합니까?

@jonjaques Btw 당신은 T를 절대 사용하지 않습니다. 또한 이것은 메서드를 재정의하는 내가 설명한 문제를 해결하지 못합니다.

언급한 솔루션은 이미 거의 4년 전에 제안된 것 같습니다. 하지만 아직 문제를 해결하는 것은 아닙니다.

누군가가 알고 있을 수 있는 다른 해결 방법이 있고 누군가 내가 겪고 있는 문제에 대한 좋은 요약이 있는지 확인하기 위해 stackoverflow 를 열었습니다.

"이 매개변수를 포함하여 메서드 매개변수로 사용되는 제네릭은 반공변인 것 같지만 실제로는 항상 이 매개변수가 공변(또는 심지어 이변)으로 처리되기를 원합니다."

따라서 이것은 실제로 TypeScript 자체에서 손상되어 수정되어야 하는 것 같습니다('this'는 공변 또는 이변이어야 함).

편집: 이 의견에는 더 나은 방법이 있습니다.

추가할 내용이 많지는 않지만 https://github.com/microsoft/TypeScript/issues/5863#issuecomment -437217433 에서 잘 작동했습니다.

class Foo {
    static create<T extends typeof Foo>(this: T): InstanceType<T> {
        return (new this()) as InstanceType<T>;
    }
}

class Bar extends Foo { }

// typeof b is Bar.
const b = Bar.create()

이 긴 문제를 탐색하고 싶지 않은 사람에게 이것이 유용하기를 바랍니다.

또 다른 사용 사례는 클래스가 아닌 사용자 정의 유형 가드 멤버 함수입니다.

type Baz = {
    type: "baz"
}
type Bar = {
     type: "bar"
}
type Foo = (Baz|Bar)&{
    isBar: () => this is Bar 
}

해결 방법은 내가 있어야 할 곳에 거의 도달하지만 기어에 던질 렌치가 하나 더 있습니다. 다음과 같은 인위적인 예를 들어 보십시오.

interface IAutomobileOptions {
  make: string
}

interface ITruckOptions extends IAutomobileOptions {
  bedLength: number
}

export class Automobile<O extends IAutomobileOptions> {
  constructor(public options: O) {}

  static create<T extends typeof Automobile, O extends IAutomobileOptions>(
    this: T,
    options: O
  ): InstanceType<T> {
    return new this(options) as InstanceType<T>
  }
}

export class Truck<O extends ITruckOptions> extends Automobile<O> {
  constructor(truckOptions: O) {
    super(truckOptions)
  }
}

const car = Automobile.create({ make: 'Audi' })
const truck = Truck.create({ make: 'Ford', bedLength: 7 }) // TS Error on Truck

다음은 오류입니다.

The 'this' context of type 'typeof Truck' is not assignable to method's 'this' of type 'typeof Automobile'.
  Types of parameters 'truckOptions' and 'options' are incompatible.
    Type 'O' is not assignable to type 'ITruckOptions'.
      Property 'bedLength' is missing in type 'IAutomobileOptions' but required in type 'ITruckOptions'.ts(2684)

Automobile 클래스의 create 메서드에는 ITruckOptions ~ O 에 대한 참조가 없기 때문에 이것이 의미가 있습니다. 그 문제에 대한 해결 방법?

일반적으로 생성자에 대한 확장 클래스의 옵션은 기본 클래스의 옵션 인터페이스를 확장하므로 기본 클래스에 대한 매개변수가 항상 포함된다는 것을 알고 있지만 확장에 대한 매개변수를 포함하는지 확인하는 안정적인 방법이 없습니다. 등급.

나는 또한 상속 클래스의 예상 입력 및 반환 유형에 대해 알리기 위해 클래스를 확장할 때 메서드를 재정의하는 데 의존해야 했습니다.

@Jack-Barry가 작동합니다.

interface IAutomobileOptions {
  make: string
}

interface ITruckOptions extends IAutomobileOptions {
  bedLength: number
}

export class Automobile<O extends IAutomobileOptions> {
  constructor(public options: O) { }

  static create<T extends Automobile<O>, O extends IAutomobileOptions>(
    this: { new(options: O): T; },
    options: O
  ): T {
    return new this(options)
  }
}

export class Truck<O extends ITruckOptions> extends Automobile<O> {
  constructor(truckOptions: O) {
    super(truckOptions)
  }
}

const car = Automobile.create({ make: 'Audi' });
const truck = Truck.create({ make: 'Ford', bedLength: 7 });

그러나 생성자가 공용이므로 new Automobile({ make: "Audi" }) 만 수행할 수 있으므로 여전히 이상적이지 않습니다.

@elderapo 나는 그것이 내가 필요한 것을 얻는다고 생각합니다. 예는 물론 고안된 것이지만 _Generics_에 대한 이해 부족이 저를 조금 괴롭힌 부분을 봅니다. 정리해주셔서 감사합니다!

바라건대 이것이 다른 사람들에게 도움이되기를 바랍니다. 개선의 여지가 있으면 알려주십시오. 읽기 기능이 잠재적으로 타이핑과 동기화되지 않을 수 있기 때문에 완벽하지는 않지만 필요한 패턴에 가장 가깝습니다.

// Interface to ensure attributes that exist on all descendants
interface IBaseClassAttributes {
  foo: string
}

// Type to provide inferred instance of class
type ThisClass<
  Attributes extends IBaseClassAttributes,
  InstanceType extends BaseClass<Attributes>
> = {
  new (attributes: Attributes): InstanceType
}

// Constructor uses generic A to assign attributes on instances
class BaseClass<A extends IBaseClassAttributes = IBaseClassAttributes> {
  constructor(public attributes: A) {}

  // this returns an instance of type ThisClass
  public static create<A extends IBaseClassAttributes, T extends BaseClass<A>>(
    this: ThisClass<A, T>,
    attributes: A
  ): T {
    // Perform db creation actions here
    return new this(attributes)
  }

  // Note that read function is a place where typechecking could fail you if db
  //   return value does not match
  public static read<A extends IBaseClassAttributes>(id: string): A | null {
    // Perform db retrieval here assign to variable
    const dbReturnValue = {} as A | null
    return dbReturnValue
  }
}

interface IExtendingClassAttributes extends IBaseClassAttributes {
  bar: number
}

// Extend the BaseClass with the extending attributes interface
class ExtendingClass extends BaseClass<IExtendingClassAttributes> {}

// BaseClass
const bc: BaseClass = BaseClass.create({ foo: '' })
const bca: IBaseClassAttributes = BaseClass.read('a') as IBaseClassAttributes
console.log(bc.attributes.foo)
console.log(bca.foo)

// ExtendingClass
// Note that the create and read methods do not have to be overriden,
//  but typechecking still works as expected here
const ec: ExtendingClass = ExtendingClass.create({ foo: 'bar', bar: 0 })
const eca: IExtendingClassAttributes = ExtendingClass.read(
  'a'
) as IExtendingClassAttributes
console.log(ec.attributes.foo)
console.log(ec.attributes.bar)
console.log(eca.foo)
console.log(eca.bar)

이 패턴을 나머지 CRUD 작업으로 쉽게 확장할 수 있습니다.

@Jack-Barry의 예에서 클래스의 인스턴스를 반환하는 read 함수를 얻으려고 합니다. 다음이 작동할 것으로 예상했습니다.

class BaseClass<A extends IBaseClassAttributes = IBaseClassAttributes> {

  public static read<A extends IBaseClassAttributes, T extends BaseClass<A>>(
    this: ThisClass<A, T>,
    id: string,
  ): T | null {
    // Perform db retrieval here assign to variable
    const dbReturnValue = {} as A | null
    if (dbReturnValue === null) {
      return null;
    }
    return this.create(dbReturnValue);
  }
}

하지만 대신 Property 'create' does not exist on type 'ThisClass<A, T>'. 오류가 발생합니다. 이 문제를 해결하는 방법에 대한 해결 방법이 있는 사람이 있습니까?

@everhardt create 메서드는 static 이므로 인스턴스가 아닌 this 의 class 에서 호출해야 합니다. 즉, 여전히 원하는 유형 검사를 제공하는 class 함수에 동적으로 액세스하는 방법에 대한 좋은 해결 방법이 없습니다.

내가 얻을 수있는 가장 가까운 것은 특히 우아하지 않고 BaseClass.create 의 기존 type 을 사용할 수 없으므로 쉽게 동기화되지 않을 수 있습니다.

return (this.constructor as unknown as { create: (attributes: A) => T }).create(dbReturnValue)

나는 이것을 _ 테스트하지 _ 하지 않았습니다 .

@Jack-Barry 그러면 this.constructor.create is not a function 를 얻습니다.

그것은 의미가 있습니다. Typescript는 this 를 인스턴스로 해석하지만 최종 자바 스크립트 파서의 경우 함수가 정적이므로 this 가 클래스입니다.

Jack-Barry의 예에서 가장 영감을 받은 확장은 아닐지 모르지만 이 Playground Link 에서 내가 어떻게 해결했는지 볼 수 있습니다.

요점:

• ThisClass 유형은 BaseClass의 메소드(정적 및 인스턴스 모두)가 다형성 'this'와 함께 사용하려는 모든 정적 속성 및 메소드를 설명해야 합니다.
• 인스턴스 메서드에서 정적 속성이나 메서드를 사용할 때 (this.constructor as ThisClass<A, this>) 를 사용합니다.

클래스와 ThisClass 유형 모두에서 정적 메서드 및 속성 유형을 정의해야 하므로 이중 작업이지만 저에게는 작동합니다.

편집: 놀이터 링크 수정

PHP는 오래전에 이 문제를 수정했습니다. 본인. 공전. 이것.

안녕하세요, 2020년입니다. _this_ 문제가 있습니다. 😛

class Animal { 
  static create() { 
    return new this()
  }
}
class Bunny extends Animal {}
const bugs = Bunny.create() // const bugs: Animal

bugs 가 Bunny 의 인스턴스가 될 것으로 예상합니다.

현재 해결 방법은 무엇입니까? 이 문제에서 모든 것을 시도했지만 아무 것도 해결되지 않는 것 같습니다.

업데이트 : 이것은 효과가 있었고 this 인수 정의를 놓쳤습니다.

class Animal { 
  static create<T extends typeof Animal>(this: T): InstanceType<T> { 
    return (new this()) as InstanceType<T>
  }
}
class Bunny extends Animal {}
const bugs = Bunny.create() // const bugs: Bunny

문제는 getter와 setter가 유형 매개변수를 가질 수 없다는 것입니다.

너무 장황합니다.

나는 비슷한 문제를 다루고 있습니다. "다형성 내부 클래스"를 구현하기 위해 내가 찾을 수 있는 최선은 다음과 같습니다.

class BaseClass {
  static InnerClass = class BaseInnerClass {};

  static createInnerClass<T extends typeof BaseClass>(this: T) {
    return new this.InnerClass() as InstanceType<T['InnerClass']>;
  }
}

class SubClass extends BaseClass {
  static InnerClass = class SubInnerClass extends BaseClass.InnerClass {};
}

const baseInnerClass = BaseClass.createInnerClass(); // => BaseInnerClass

const subInnerClass = SubClass.createInnerClass(); // => SubInnerClass

잘 작동하는 것 같지만 createInnerClass() 를 입력하는 것은 내 생각에 너무 장황하며 내 코드베이스에 많은 항목이 있을 것입니다. 누구든지 이 코드를 단순화하는 방법에 대한 아이디어가 있습니까?

이 접근 방식의 문제는 정적 getter 및 setter에서 작동하지 않는다는 것입니다.

정적 속성에 대해 self. 를 구현하는 것은 어떻습니까? 나는 4 년 전에이 문제가 있었고 같은 문제로 같은 스레드로 돌아 왔습니다.

@sudommaxime ECMAScript 가 클래스에서 this.constructor. 에 대한 별칭으로 기본적으로 self. 를 지원하지 않는 한 TypeScript 설계 목표와 반대로 실행됩니다. self 가 공통 변수 이름인 경우 발생합니다.

@abdullah-kasim의 솔루션은 설명된 대로 작동하는 것 같지만 일반 클래스에서 작동하도록 할 수 없습니다.

class Animal<A> {
  public thing?: A;

  static create<T extends typeof Animal>(this: T): InstanceType<T> {
    return new this() as InstanceType<T>;
  }
}

type Foo = {};
class Bunny extends Animal<Foo> {}

const bunny = Bunny.create(); // typeof bunny is Animal<unknown>
bunny.thing;                  // unknown :(

   __     __
  /_/|   |\_\  
   |U|___|U|
   |       |
   | ,   , |
  (  = Y =  )
   |   `  |
  /|       |\
  \| |   | |/
 (_|_|___|_|_)
   '"'   '"'

운이 없이 잠시 고민해 보았으므로 이것이 가능한지 생각해주시면 감사하겠습니다.

@stevehanson 이것이 당신에게 효과가 있습니까?

class Animal<A> {
  public thing?: A;

  static create<T>(this: new () => T): T {
    return new this() as T;
  }
}

type Foo = {asd: 123};
class Bunny extends Animal<Foo> {
    public hiya: string = "hi there"
}

const bunny = Bunny.create()


bunny.thing

const test = bunny.thing?.asd

const hiya = bunny.hiya

typescript 놀이터에서 이것을 테스트했습니다.

이 링크에서 영감:
https://selleo.com/til/posts/gll9bsvjcj-generic-with-class-as-argument-and-returning-instance

그리고 T 가 클래스 자체라는 것을 어떻게 암시했는지 잘 모르겠습니다 . 편집: 아, 자동 this 매개변수가 항상 클래스 자체를 전달하기 때문에 T를 암시하는 것으로 기억했습니다.

@abdullah-kasim 작동했습니다! 우와, 고마워요! 내 특정 경우에 내 생성자는 인수를 취하므로 다른 사람에게 도움이 될 경우를 대비하여 다음과 같이 표시되었습니다.

  static define<C, T, F = any, I = any>(
    this: new (generator: GeneratorFn<T, F, I>) => C,
    generator: GeneratorFn<T, F, I>,
  ): C {
    return new this(generator);
  }

여기에 있는 일부 솔루션은 다음에서 인수를 전달할 수 없기 때문에 정적 getter에서 작동하지 않습니다.

아래 예에서 default 정적 getter를 상위 클래스로 이동하는 방법은 무엇입니까?

class Letters {
  alpha: string = 'alpha'
  beta?: string
  gamma?: string
  static get default () {
    return new this()
  }
}

const x = Letters.default.alpha;

이것은 구문 개선을 고려한다면 고려할 가치가 있는 것일 수 있습니다.

관련 가능성: @abdullah-kasim 의 예제에 다른 추상화 계층을 추가하는 데 어려움을 겪고 있습니다. 본질적으로 저는 Animal 를 인터페이스로 바꾸고 Bunny 가 자신의 정적 create() $ 을 정의하도록 허용하고 싶습니다.

다음은 실용적인 예입니다(토끼 비유를 포기한 것을 용서하십시오!). 나는 몇 가지 다른 문서 유형을 정의할 수 있기를 원하고 각각은 문자열을 문서 인스턴스로 바꾸는 정적 팩토리 메소드를 정의할 수 있어야 합니다. 문서 유형이 다른 문서 유형이 아닌 자체에 대해서만 파서를 정의해야 한다고 강제하고 싶습니다.

(아래 예의 유형은 정확하지 않습니다. 바라건대 내가 달성하려는 것이 충분히 명확하기를 바랍니다.)

interface ParseableDoc {
    parse<T>(this: new () => T, serialized:string): T|null;
}

interface Doc {
    getMetadata():string;
}

// EXPECT: no error!
const MarkdownDoc:ParseableDoc = class implements Doc {
    constructor(private meta:string){ };
    getMetadata():string { return this.meta; };

    static parse(serialized:string):typeof MarkdownDoc | null {
        // do something specific
        return null;
    }
}

// EXPECT: type error, since class defines no static parse()
const MissingParseDoc:ParseableDoc = class implements Doc {
    constructor(private meta:string){ };
    getMetadata():string { return this.meta; };
}

// EXPECT: type error, since parse() should return a MismatchedDoc
const MismatchDoc: ParseableDoc = class implements Doc {
    constructor(private meta:string){ };
    getMetadata():string { return this.meta; };

    static parse(serialized:string):typeof MismatchDoc | null {
        // do something specific
        return null;
    }
}

(제 생각에는) 다음과 같이 쓸 수 있기를 바랍니다.

interface ParseableDoc {
    getMetadata():string;
    static parse<T extends ParseableDoc>(this: new () => T, serialized:string): T|null;
}

class MarkdownDoc implements ParseableDoc {
    getMetadata():string { return ""; }

    static parse(serialized:string):MarkdownDoc|null {
        // do something specific
        return null;
    }
}

여기에서도 해결 방법이 가능한지 알 수 있습니까?

편집: 가능한 해결 방법

StackOverflow의 또 다른 사용 사례
일반 조회 테이블 클래스를 설계하기 위해.

// Generic part
abstract class Table<T extends Model> {
    instances: Map<number, T> = new Map();
}
abstract class Model {
    constructor(
        public readonly id: number,
        public table: Table<this>  // Error
    ) { 
        table.instances.set(id, this);
    }
}

// Example: a table of Person objects
class Person extends Model {
    constructor(
        id: number,
        table: Table<this>,  // Error
        public name: string
    ) {
        super(id, table);
    }
}
class PersonTable extends Table<Person> {}

const personTable = new PersonTable();
const person = new Person(0, personTable, 'John Doe');

// Note: the idea of using `this` as generic type argument is to guarantee
// that other models cannot be added to a table of persons, e.g. this would fail:
//     class SomeModel extends Model { prop = 0; }
//     const someModel = new SomeModel(1, person.table);
//                                        ^^^^^^^^^^^^

@Think7 이 2016년 5월 29일에 댓글을 남겼습니다.
😰 이게 아직도 수정/추가가 안되었다는게 믿기지 않는다.....

ㅋ
2020년이 왔다!

이것은 우스꽝스럽고 미친 짓입니다. 2020년이네요. 4년이 지난 지금, 왜 안 고쳐졌을까요?

다음과 같은 것을 구현하지 않는 이유

class Model {
  static create(){
     return new static()
  }
  //or
  static create(): this {
     return new this()
  }
}

class User extends Model {
  //...
}

let user = new User.create() // type === User