정적 인터페이스 메서드는 일반적으로 의미가 없습니다. #13462 참조

더 많은 피드백이 들릴 때까지 보류합니다.

이것을 고려할 때 우리가 가진 주요 질문: abstract static 메소드를 호출할 수 있는 사람은 누구입니까? 아마도 AbstractParentClass.getSomeClassDependentValue 를 직접 호출할 수 없습니다. 그러나 AbstractParentClass 유형의 표현식에서 메소드를 호출할 수 있습니까? 그렇다면 왜 허용되어야 합니까? 그렇지 않은 경우 기능의 용도는 무엇입니까?

정적 인터페이스 메서드는 일반적으로 의미가 없습니다. #13462 참조

#13462에 대한 토론에서 static 인터페이스 메서드가 무의미한 이유를 알지 못했습니다. 나는 그들의 기능이 다른 수단으로 구현될 수 있다는 것을 보았을 뿐입니다.

실용적인 관점에서 인터페이스는 일종의 사양입니다. 이 인터페이스를 구현하는 클래스에서 구현하는 데 필수적인 특정 메서드 집합입니다. 인터페이스는 개체가 제공하는 기능을 정의할 뿐만 아니라 일종의 계약이기도 합니다.

따라서 class 에는 static 메서드가 있고 interface 에는 없는 논리적 이유가 없습니다.

언어로 이미 구현될 수 있는 모든 것은 구문 및 기타 사항의 개선이 필요하지 않다는 관점(즉, 이 인수는 #13462에 대한 논의의 주요 요점 중 하나임)을 따르는 경우 다음과 같이 안내됩니다. 관점에서 볼 때 for 와 if 를 함께 사용하여 구현할 수 있으므로 while 주기가 중복된다고 결정할 수 있습니다. 그러나 우리는 while 를 없애지 않을 것입니다.

이것을 고려할 때 우리가 가진 주요 질문: abstract static 메소드를 호출할 수 있는 사람은 누구입니까? 아마도 AbstractParentClass.getSomeClassDependentValue 를 직접 호출할 수 없습니다. 그러나 AbstractParentClass 유형의 표현식에서 메소드를 호출할 수 있습니까? 그렇다면 왜 허용되어야 합니까? 그렇지 않은 경우 기능의 용도는 무엇입니까?

좋은 질문. 이 문제를 고려 중이시므로 이에 대한 아이디어를 공유해 주시겠습니까?

컴파일러 수준에서 AbstractParentClass.getSomeClassDependentValue 직접 호출의 경우는 추적되지 않고(추적할 수 없기 때문에) JS 런타임 오류가 발생한다는 것이 제 마음에 떠오릅니다. 그러나 이것이 TypeScript 이념과 일치하는지 확실하지 않습니다.

나는 그들의 기능이 다른 수단으로 구현될 수 있다는 것을 보았을 뿐입니다.

구현 가능하다고 해서 의미가 있는 것은 아닙니다. 😉

abstract class Serializable {  
    abstract serialize (): Object;  
    abstract static deserialize (Object): Serializable;  
}  

Serializable의 하위 클래스에서 정적 역직렬화 메서드를 강제로 구현하고 싶습니다.
그러한 동작을 구현하기 위한 해결 방법이 있습니까?

이에 대한 최신 정보는 무엇입니까? 방금 추상 클래스의 추상 정적 속성을 작성하려고 시도했는데 허용되지 않을 때 정말 놀랐습니다.

@patryk-zielinski93이 말한 것. TS로 변환하는 PHP 프로젝트에서 몇 년 동안 인터페이스에 정적 메서드가 필요합니다.

이것이 도움이 될 매우 일반적인 사용 사례는 displayName , propTypes 및 defaultProps 와 같은 정적 속성이 있는 클래스인 React 구성 요소입니다.

이러한 제한으로 인해 현재 React의 입력에는 Component 클래스와 생성자 함수 및 정적 속성을 포함하는 ComponentClass 인터페이스의 두 가지 유형이 포함됩니다.

모든 정적 속성이 있는 React 구성 요소를 완전히 유형 확인하려면 두 가지 유형을 모두 사용합니다.

ComponentClass 가 없는 예: 정적 속성은 무시됩니다.

import React, { Component, ComponentClass } from 'react';

type Props = { name: string };

{
  class ReactComponent extends Component<Props, any> {
    // expected error, but got none: displayName should be a string
    static displayName = 1
    // expected error, but got none: defaultProps.name should be a string
    static defaultProps = { name: 1 }
  };
}

ComponentClass 가 있는 예: 정적 속성은 유형이 검사됩니다.

{
  // error: displayName should be a string
  // error: defaultProps.name should be a string
  const ReactComponent: ComponentClass<Props> = class extends Component<Props, any> {
    static displayName = 1
    static defaultProps = { name: 1 }
  };
}

많은 사람들이 현재 ComponentClass 를 사용하지 않고 있다고 생각합니다. 정적 속성이 유형 검사되지 않는다는 사실을 모르고 있습니다.

관련 문제: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/16967

이에 대한 진전이 있습니까? 또는 추상 클래스의 생성자에 대한 해결 방법이 있습니까?
다음은 예입니다.

abstract class Model {
    abstract static fromString(value: string): Model
}

class Animal extends Model {
    constructor(public name: string, public weight: number) {}

    static fromString(value: string): Animal {
        return new Animal(...JSON.parse(value))
    }
}

@로보슬론

class Animal {
    static fromString(value: string): Animal {
        return new Animal();
    }
}

function useModel<T>(model: { fromString(value: string): T }): T {
    return model.fromString("");
}

useModel(Animal); // Works!

이것은 매우 강력하고 유용한 기능이라는 데 동의했습니다. 제 생각에는 이 기능이 수업을 '일등 시민'으로 만드는 것입니다. 클래스/정적 메서드의 상속은 특히 여기에서 다른 포스터에 의해 여러 번 호출된 정적 메서드 팩토리 패턴에 대해 의미가 있을 수 있고 또 그렇게 합니다. 이 패턴은 TypeScript에서 자주 수행되는 작업인 역직렬화에 특히 유용합니다. 예를 들어, 모든 구현 유형이 JSON에서 인스턴스화할 수 있음을 명시하는 계약을 제공하는 인터페이스를 정의하려는 것이 완벽합니다.

추상 정적 팩토리 메서드를 허용하지 않으면 구현자가 대신 추상 팩토리 클래스를 생성해야 하므로 클래스 정의 수가 불필요하게 두 배로 늘어납니다. 그리고 다른 포스터에서 지적했듯이 이것은 PHP 및 Python과 같은 다른 언어로 구현된 강력하고 성공적인 기능입니다.

Typescript를 처음 사용하지만 기본적으로 이것이 허용되지 않는다는 점과 많은 사람들이 다음 중 하나로 기능을 추가하지 않는 것을 정당화하려고 한다는 사실에 놀랐습니다.

1. TS는 기능이 필요하지 않습니다. 왜냐하면 당신은 여전히 ​​다른 수단을 통해 당신이 하려고 하는 것을 성취할 수 있기 때문입니다. 아주 작은)
2. 우리가 할 수 있다고해서 우리가해야한다는 의미는 아닙니다. 훌륭함: 그러나 사람들은 그것이 얼마나 유용하고 유익한지에 대한 구체적인 예를 게시하고 있습니다. 그것을 허용하는 것이 얼마나 상처를 줄 수 있는지 모르겠습니다.

또 다른 간단한 사용 사례: (작동하지 않는 이상적인 방법)

import {map} from 'lodash';

export abstract class BaseListModel {
  abstract static get instance_type();

  items: any[];

  constructor(items?: any[]) {
    this.items = map(items, (item) => { return new this.constructor.instance_type(item) });
  }

  get length() { return this.items.length; }
}

export class QuestionList extends BaseListModel {
  static get instance_type() { return Question }
}

대신 목록 인스턴스는 목록 인스턴스 자체와 관련이 없고 생성자를 통해 액세스해야 하는 인스턴스 유형을 직접 노출하게 됩니다. 더러운 느낌. 같은 종류의 메커니즘 등을 통해 일련의 기본값을 지정하는 레코드 모델에 대해 이야기한다면 훨씬 더 더럽게 느껴질 것입니다.

나는 Ruby/javascript를 오랫동안 사용한 후 언어에서 실제 추상 클래스를 사용하게 되어 정말 기뻤습니다. 결국 구현 제한 사항에 실망하게 되었습니다. 유용할 다른 사용 사례. 주로 정적 인터페이스의 일부로 간단한 DSL/구성을 생성하는 수단으로 클래스가 기본값 개체 또는 무엇이든 지정하도록 합니다. - 그리고 당신은 생각하고 있을지도 모릅니다. 그게 바로 인터페이스의 용도입니다. 그러나 이와 같이 단순한 것의 경우에는 실제로 의미가 없으며 필요한 것보다 더 복잡한 것으로 끝납니다. 등).

내 프로젝트에 대해 이와 유사한 요구 사항이 두 번 있었습니다. 둘 다 모든 하위 클래스가 정적 메서드 집합의 구체적인 구현을 제공하도록 보장하는 것과 관련이 있습니다. 내 시나리오는 다음과 같습니다.

class Action {
  constructor(public type='') {}
}

class AddAppleAction extends Action {
  static create(apple: Apple) {
    return new this(apple);
  }
  constructor(public apple: Apple) {
    super('add/apple');
  }
}

class AddPearAction extends Action {
  static create(pear: Pear) {
    return new this(pear);
  }

  constructor(public pear: Pear) {
    super('add/pear');
  }
}

const ActionCreators = {
  addApple: AddAppleAction
  addPear: AddPearAction
};

const getActionCreators = <T extends Action>(map: { [key: string]: T }) => {
  return Object.entries(map).reduce((creators, [key, ActionClass]) => ({
    ...creators,
    // To have this function run properly,
    // I need to guarantee that each ActionClass (subclass of Action) has a static create method defined.
    // This is where I want to use abstract class or interface to enforce this logic.
    // I have some work around to achieve this by using interface and class decorator, but it feels tricky and buggy. A native support for abstract class method would be really helpful here.
    [key]: ActionClass.create.bind(ActionClass)
  }), {});
};

이것이 내 요구 사항을 설명할 수 있기를 바랍니다. 감사 해요.

해결 방법 을 찾는 사람은 다음 데코레이터를 사용할 수 있습니다.

class myClass {
    public classProp: string;
}

interface myConstructor {
    new(): myClass;

    public readonly staticProp: string;
}

function StaticImplements <T>() {
    return (constructor: T) => { };
}

<strong i="7">@StaticImplements</strong> <myConstructor>()
class myClass implements myClass {}

const getActionCreators = <T extends Action>(map: { [key: string]: {new () => T, create() : T}}) => {

유형 매개변수를 통해 호출하기 때문에 가상의 abstract static 팩토리 메소드가 있는 실제 기본 클래스는 절대 관련되지 않습니다. 하위 클래스의 유형은 유형 매개변수가 인스턴스화될 때 구조적으로 관련됩니다.

이 토론에서 내가 보지 못한 것은 일부 합성 유형이 아닌 기본 클래스 유형을 통해 구현이 호출되는 경우입니다.

abstract 멤버가 파생 클래스, JavaScript 멤버 구현, 인스턴스 또는 기타의 구현에 의해 실제로 _재정의_되는 C#과 같은 언어와 달리 상속된 숫자를 재정의하지 않고 오히려 _shadow_한다는 점을 고려하는 것도 관련이 있습니다.

사용자 관점에서 내 5센트는 다음과 같습니다.

인터페이스의 경우 _static_ 수정자를 허용해야 합니다.

인터페이스는 클래스를 구현하여 이행할 계약을 정의합니다. 이것은 인터페이스가 클래스보다 높은 수준의 추상화임을 의미합니다.

지금 내가 볼 수 있는 것은 클래스가 인터페이스보다 더 표현적일 수 있다는 것입니다. 클래스에 정적 메서드를 가질 수 있지만 계약 정의 자체에서 이를 강제할 수는 없습니다.

제 생각에는 그것이 잘못되고 방해되는 것 같습니다.

이 언어 기능을 구현하기 어렵거나 불가능하게 만드는 기술적 배경이 있습니까?

건배

인터페이스는 클래스를 구현하여 이행할 계약을 정의합니다. 이것은 인터페이스가 클래스보다 높은 수준의 추상화임을 의미합니다.

클래스에는 2개의 인터페이스, 2개의 구현 계약이 있으며, 이로부터 벗어날 수 없습니다.
C#과 같은 언어에는 인터페이스에 대한 정적 멤버도 없는 이유가 있습니다. 논리적으로 인터페이스는 객체의 공개 표면입니다. 인터페이스는 개체의 공개 표면을 설명합니다. 즉, 거기에 없는 것은 포함하지 않습니다. 클래스의 인스턴스에서 정적 메서드는 인스턴스에 존재하지 않습니다. 클래스/생성자 함수에만 존재하므로 해당 인터페이스에서만 설명해야 합니다.

클래스의 인스턴스에서 정적 메서드는 인스턴스에 존재하지 않습니다.

그것에 대해 자세히 설명할 수 있습니까? 이것은 C#이 아닙니다.

클래스/생성자 함수에만 존재하므로 해당 인터페이스에서만 설명해야 합니다.

우리는 그것을 얻었고 그것이 우리가 바꾸고 싶은 것입니다.

인터페이스는 클래스를 구현하여 이행할 계약을 정의합니다. 이것은 인터페이스가 클래스보다 높은 수준의 추상화임을 의미합니다.

나는 그것에 전적으로 동의합니다. Json 인터페이스 예제 보기

안녕하세요 @kitsonk님 , 다음에 대해 자세히 설명해 주시겠습니까?

클래스에는 2개의 인터페이스, 2개의 구현 계약이 있으며, 이로부터 벗어날 수 없습니다.

그 부분이 이해가 되지 않았습니다.

논리적으로 인터페이스는 객체의 공개 표면입니다. 인터페이스는 개체의 공개 표면을 설명합니다. 즉, 거기에 없는 것은 포함하지 않습니다.

동의한다. 나는 내가 말한 것과 모순되는 것을 보지 못한다. 나는 더 많은 말을 하기도 했다. 인터페이스는 클래스 가 수행될 계약이라고 말했습니다.

클래스의 인스턴스에서 정적 메서드는 인스턴스에 존재하지 않습니다. 클래스/생성자 함수에만 존재하므로 해당 인터페이스에서만 설명해야 합니다.

내가 이 권리를 이해했는지 확실하지 않습니다. 그것이 말하는 내용은 분명하지만 왜 그렇게 말했는지는 알 수 없습니다. 내 말이 여전히 유효하다고 생각하는 이유를 설명할 수 있습니다. 나는 항상 인터페이스를 매개변수로 내 메서드에 전달하고 있습니다. 즉, 인터페이스 메서드에 액세스할 수 있습니다. 여기서 인터페이스를 데이터 구조를 정의하는 방법으로 사용하는 것이 아니라 다른 곳에서 생성/수화되는 구체적인 개체를 정의하는 방법으로 사용한다는 점에 유의하십시오. . 그래서 내가 가지고있을 때 :

fetchData(account: SalesRepresentativeInterface): Observable<Array<AccountModel>> {
    // Method Body
}

해당 메서드 본문에서 실제로 account 메서드를 사용할 수 있습니다. 내가 할 수 있기를 바라는 것은 account 에서 받는 클래스가 무엇이든 간에 이미 구현되도록 강제된 SalesRepresentativeInterface 의 정적 메서드를 사용할 수 있게 하는 것입니다. 아마도 기능을 사용하는 방법에 대해 매우 단순하거나 완전히 잘못된 생각을 하고 있을 수 있습니다.

static 수정자를 허용하면 SalesRepresentativeInterface.staticMethodCall() 와 같은 작업을 수행할 수 있다고 생각합니다.

내가 잘못 ?

건배

@davidmpaz : 구문이 정확하지 않지만 가깝습니다. 다음은 사용 패턴의 예입니다.

interface JSONSerializable {
  static fromJSON(json: any): JSONSerializable;
  toJSON(): any;
}

function makeInstance<T extends JSONSerializable>(cls: typeof T): T {
  return cls.fromJSON({});
}

class ImplementsJSONSerializable implements JSONSerializable {
  constructor(private json: any) {
  }
  static fromJSON(json: any): ImplementsJSONSerializable {
    return new ImplementsJSONSerializable(json);
  }
  toJSON(): any {
    return this.json;
  }
}

// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializable);

불행히도 이것이 작동하려면 TypeScript의 두 가지 기능이 필요합니다. (1) 인터페이스의 정적 메서드와 추상 정적 메서드; (2) typeof 를 일반 클래스의 유형 힌트로 사용하는 기능.

@davidmpaz

그 부분이 이해가 되지 않았습니다.

클래스에는 두 개의 인터페이스가 있습니다. 생성자 함수와 인스턴스 프로토타입. 키워드 class 는 본질적으로 설탕입니다.

interface Foo {
  bar(): void;
}

interface FooConstructor {
  new (): Foo;
  prototype: Foo;
  baz(): void;
}

declare const Foo: FooConstructor;

const foo = new Foo();
foo.bar();  // instance method
Foo.baz(); // static method

@jimmykane

그것에 대해 자세히 설명할 수 있습니까? 이것은 C#이 아닙니다.

class Foo {
    bar() {}
    static baz() {}
}

const foo = new Foo();

foo.bar();
Foo.baz();

Foo 의 인스턴스에는 .baz() 가 없습니다. .baz() 는 생성자에만 존재합니다.

유형 관점에서 이 두 인터페이스를 참조/추출할 수 있습니다. Foo 는 공용 인스턴스 인터페이스를 나타내고 typeof Foo 는 공용 생성자 인터페이스(정적 메서드를 포함함)를 나타냅니다.

@kitsonk 의 설명을 따르기 위해 원하는 것을 달성하기 위해 위의 예를 다시 작성했습니다.

interface JSONSerializable <T>{
    fromJSON(json: any): T;
}

function makeInstance<T>(cls: JSONSerializable<T>): T {
    return cls.fromJSON({});
}

class ImplementsJSONSerializable {
    constructor (private json: any) {
    }
    static fromJSON(json: any): ImplementsJSONSerializable {
        return new ImplementsJSONSerializable(json);
    }
    toJSON(): any {
        return this.json;
    }
}

// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializable); 

참고:

• implements 절은 실제로 필요하지 않습니다. 클래스를 사용할 때마다 구조적 검사가 수행되고 클래스가 필요한 인터페이스와 일치하도록 유효성이 검사됩니다.
• 생성자 유형을 가져오기 위해 typeof 가 필요하지 않습니다. T 가 캡처하려는 것인지 확인하십시오.

@mhegazy : JSONSerializable 인터페이스에서 내 toJSON 호출을 제거해야 했습니다. 내 간단한 예제 함수 makeInstance 는 fromJSON $ 만 호출하지만 개체를 ​​인스턴스화한 다음 사용하는 것이 매우 일반적입니다. T 가 makeInstance 안에 있는지 실제로 알지 못하기 때문에 makeInstance 에서 반환된 항목에 대해 전화를 걸 수 있는 기능을 제거했습니다(특히 makeInstance 는 인스턴스를 생성한 다음 사용하기 위해 내부적으로 사용되는 클래스 메서드입니다). 물론 나는 이것을 할 수 있다:

interface JSONSerializer {
  toJSON(): any;
}

interface JSONSerializable <T extends JSONSerializer> {
  fromJSON(json: any): T;
}

function makeInstance<T extends JSONSerializer>(cls: JSONSerializable<T>): T {
  return cls.fromJSON({});
}

class ImplementsJSONSerializer implements JSONSerializer {
  constructor (private json: any) {
  }
  static fromJSON(json: any): ImplementsJSONSerializer {
    return new ImplementsJSONSerializer(json);
  }
  toJSON(): any {
    return this.json;
  }
}

// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializer);

그리고 이제 내 T 에 JSONSerializer 에서 사용할 수 있는 모든 방법이 있다는 것을 알고 있습니다. 그러나 이것은 지나치게 장황하고 추론하기 어렵습니다(잠깐만, 당신은 ImplementsJSONSerializer 을 전달하고 있지만 이것은 JSONSerializable 가 아닙니다. 맞습니까? 잠깐, 당신은 오리 타이핑입니까??) . 버전에 대해 더 쉽게 추론할 수 있는 방법은 다음과 같습니다.

interface JSONSerializer {
  toJSON(): any;
}

interface JSONSerializable <T extends JSONSerializer> {
  fromJSON(json: any): T;
}

function makeInstance<T extends JSONSerializer>(cls: JSONSerializable<T>): T {
  return cls.fromJSON({});
}

class ImplementsJSONSerializer implements JSONSerializer {
  constructor (private json: any) {
  }
  toJSON(): any {
    return this.json;
  }
}

class ImplementsJSONSerializable implements JSONSerializable<ImplementsJSONSerializer> {
  fromJSON(json: any): ImplementsJSONSerializer {
    return new ImplementsJSONSerializer(json);
  }

}

// returns an instance of ImplementsJSONSerializable
makeInstance(new ImplementsJSONSerializable());

그러나 이전 의견에서 지적했듯이 이제 우리는 인스턴스화하려는 모든 클래스에 대해 팩토리 클래스를 생성해야 합니다. 이는 오리 타이핑 예제보다 훨씬 더 장황합니다. 그것은 확실히 Java에서 항상 수행되는 실행 가능한 패턴입니다(C#도 가정합니다). 그러나 불필요하게 장황하고 중복됩니다. 인터페이스에서 정적 메서드가 허용되고 추상 클래스에서 추상 정적 메서드가 허용되면 이러한 상용구는 모두 사라집니다.

추가 수업이 필요하지 않습니다. 클래스에는 static 멤버가 있을 수 있습니다. implements 절은 필요하지 않습니다. 명목형 시스템에서는 클래스에서 "is" 관계를 주장하기 위해 정말로 필요합니다. 구조적 유형 시스템에서는 실제로 필요하지 않습니다. 어쨌든 사용할 때마다 "is" 관계가 확인되므로 implements 절을 안전하게 삭제하고 안전을 느슨하게 만들 수 없습니다.

즉, 정적 fromJSON 가 있고 인스턴스에 toJSON 가 있는 클래스가 하나 있을 수 있습니다.

interface JSONSerializer {
    toJSON(): any;
}

interface JSONSerializable<T extends JSONSerializer> {
    fromJSON(json: any): T;
}

function makeInstance<T extends JSONSerializer>(cls: JSONSerializable<T>): T {
    return cls.fromJSON({});
}

class ImplementsJSONSerializer {
    constructor (private json: any) {
    }
    static fromJSON(json: any): ImplementsJSONSerializer {
        return new ImplementsJSONSerializer(json);
    }
    toJSON(): any {
        return this.json;
    }
}


// returns an instance of ImplementsJSONSerializable
makeInstance(ImplementsJSONSerializer);

@mhegazy 이미 실행 가능한 옵션으로 지적했습니다. 내 첫 번째 '덕 타이핑' 예를 참조하세요. 나는 그것이 불필요하게 장황하고 추론하기 어렵다고 주장했다. 그런 다음 (팩토리 클래스) 추론하기 쉬운 버전이 훨씬 더 장황하다고 주장했습니다.

인터페이스에 정적 메서드가 없는 문제를 해결하는 것이 가능하다는 데 동의하는 사람은 아무도 없습니다. 사실, 팩토리 클래스보다 기능적 스타일을 사용하는 더 우아한 해결 방법이 있다고 주장하고 싶습니다. 비록 그것이 제 개인적인 취향이긴 하지만요.

그러나 내 생각에는 이 예외적으로 일반적인 패턴을 구현하는 방법에 대한 가장 깔끔하고 쉬운 이유는 추상 정적 메서드를 사용하는 것입니다. 우리 중 다른 언어(Python, PHP)에서 이 기능을 사랑하게 된 사람들은 TypeScript에서 이 기능을 놓치고 있습니다. 시간 내 줘서 고마워.

그런 다음 추론하기 쉬운 버전(팩토리 클래스)이

이것이 더 쉽게 추론할 수 있다는 점에 동의하지 않습니다.

그러나 내 생각에는 이 예외적으로 일반적인 패턴을 구현하는 방법에 대한 가장 깔끔하고 쉬운 이유는 추상 정적 메서드를 사용하는 것입니다. 우리 중 다른 언어(Python, PHP)에서 이 기능을 사랑하게 된 사람들은 TypeScript에서 이 기능을 놓치고 있습니다.

그리고 이 문제는 이것을 추가하는 것을 추적하고 있습니다. 저는 이 스레드의 미래 방문자가 implements 절 없이 이것이 오늘 가능하다는 것을 이해하도록 하고 싶었습니다.

@kitsonk 맞아요. 놓쳤습니다.

얘들아, 그래서 나는 LocationModule과 같은 것을 가지고 있는데, 이것은 데이터베이스에 저장하기 위한 방법을 가져야 하고, 그로부터 스스로를 재생성해야 한다.
모든 LocationModule에는 레크리에이션 유형과 함께 고유한 옵션이 있습니다.

이제 레크리에이션을 위해 제네릭을 사용하여 팩토리를 생성해야 하지만 컴파일 시간을 확인할 수 없습니다. 여기에서 목적을 달성했습니다.

처음에는 "인터페이스에 대한 정적이 아니므로 추상 클래스를 계속 사용하겠습니다. 그러나 이것이 더러울 것입니다. 이제 내 코드 유형의 모든 곳을 인터페이스에서 추상 클래스로 변경해야 검사기가 내가 찾고 있는 메서드를 인식할 수 있기 때문입니다. .

여기:

export interface LocationModuleInterface {
  readonly name: string;

  getRecreationOptions(): ModuleRecreationOptions;
}

export abstract class AbstractLocationModule implements LocationModuleInterface {
  abstract readonly name: string;

  abstract getRecreationOptions(): ModuleRecreationOptions;

  abstract static recreateFromOptions(options: ModuleRecreationOptions): AbstractLocationModule;
}

그러다가 우연히 발견했는데 정적은 추상과 함께 할 수 없습니다. 그리고 인터페이스에 있을 수 없습니다.

얘들 아, 우리는 이것을 구현하지 않기 때문에 이것을 구현하지 않는 것을 보호하고 있지 않습니까?

저는 TypeScript를 열정적으로 사랑합니다. 미친 듯이 말이야. 그러나 항상 있습니다.

정적 메서드를 강제로 구현하는 대신 일반 이전 JavaScript에서 모든 작업을 수행하는 것처럼 다시 확인해야 합니다.

아키텍처는 이미 패턴, 멋진 결정 등으로 가득 차 있지만 그 중 일부는 인터페이스 정적 메서드와 같은 간단한 것을 사용하여 문제를 극복하기 위한 것입니다.

내 공장은 런타임에 정적 메서드 존재를 확인해야 합니다. 방법 것입니다?

또는 더 나은:

export interface LocationModuleInterface {
  readonly name: string;

  getRecreationOptions(): ModuleRecreationOptions;
  dontForgetToHaveStaticMethodForRecreation();
}

인터페이스를 구현하는 유일한 이유인 클래스 개체를 다형성으로 사용하는 경우 클래스의 정적 측면에 대한 요구 사항을 지정하는 인터페이스가 클래스 자체에서 구문적으로 참조되는지 여부는 중요하지 않습니다. 필요한 인터페이스가 구현되지 않은 경우 사용 사이트에서 확인하고 디자인 타임 오류가 발생하기 때문입니다.

@malina-kirn

내 첫 번째 '덕 타이핑' 예를 참조하세요.

이 문제는 덕 타이핑이 사용되는지 여부와 관련이 없습니다. TypeScript는 오리 형식입니다.

@aluanhaddad 귀하의 의미는 정확하지 않습니다. implements ISomeInterface 기본 함수는 클래스 객체를 다형성으로 사용하기 위한 것이라는 귀하의 요점을 이해할 수 있습니다. 그러나 클래스가 클래스 개체의 정적 모양을 설명하는 인터페이스를 참조하는지 여부는 중요할 수 있습니다.

암시적 유형 유추 및 사용 사이트 오류가 모든 사용 사례를 포괄한다고 암시합니다.
다음 예를 고려하십시오.

interface IComponent<TProps> {
    render(): JSX.Element;
}

type ComponentStaticDisplayName = 'One' | 'Two' | 'Three' | 'Four';
interface IComponentStatic<TProps> {
    defaultProps?: Partial<TProps>;
    displayName: ComponentStaticDisplayName;
    hasBeenValidated: 'Yes' | 'No';
    isFlammable: 'Yes' | 'No';
    isRadioactive: 'Yes' | 'No';
    willGoBoom: 'Yes' | 'No';
}

interface IComponentClass<TProps> extends IComponentStatic<TProps> {
    new (): IComponent<TProps> & IComponentStatic<TProps>;
}

function validateComponentStaticAtRuntime<TProps>(ComponentStatic: IComponentStatic<TProps>, values: any): void {
    if(ComponentStatic.isFlammable === 'Yes') {
        // something
    } else if(ComponentStatic.isFlammable === 'No') {
        // something else
    }
}

// This works, we've explicitly described the object using an interface
const componentStaticInstance: IComponentStatic<any> = {
    displayName: 'One',
    hasBeenValidated: 'No',
    isFlammable: 'Yes',
    isRadioactive: 'No',
    willGoBoom: 'Yes'
};

// Also works
validateComponentStaticAtRuntime(componentStaticInstance, {});

class ExampleComponent1 implements IComponent<any> {
    public render(): JSX.Element { return null; }

    public static displayName = 'One'; // inferred as type string
    public static hasBeenValidated = 'No'; // ditto ...
    public static isFlammable = 'Yes';
    public static isRadioactive = 'No';
    public static willGoBoom = 'Yes';
}

// Error: " ... not assignable to type IComponentStatic<..> ... "
validateComponentStaticAtRuntime(ExampleComponent1, {});

class ExampleComponent2 implements IComponent<any> {
    public render(): JSX.Element { return null; }

    public static displayName = 'One';
    public static hasBeenValidated = 'No';
    public static isFlammable = 'Yes';
    public static isRadioactive = 'No';
    public static willGoBoom = 'Yes';
}

// Error: " ... not assignable to type IComponentStatic<..> ... "
validateComponentStaticAtRuntime(ExampleComponent2, {});

위의 예에서는 명시적 유형 선언이 필요합니다. 클래스 개체의 모양(정적 쪽)을 설명하지 않으면 실제 값이 예상 모양과 일치하더라도 사용 사이트에서 디자인 시간 오류가 발생합니다.

또한 정적 측면을 설명하는 인터페이스를 참조하는 방법이 없기 때문에 각 개별 구성원에 대해 형식을 명시적으로 선언하는 유일한 옵션이 있습니다. 그런 다음 모든 수업에서 이를 반복합니다.

이전 게시물을 바탕으로 인터페이스의 static 수정자는 해결해야 하는 일부 사용 사례에 대한 정말 좋은 솔루션이라고 생각합니다. 이 댓글이 너무 커져서 죄송하지만 설명하고 싶은 것이 많습니다.

1) 위의 예와 같이 클래스 객체의 정적 측면 모양을 명시적으로 설명할 수 있어야 하는 경우가 있습니다.
2) 정의 사이트에서 쉐이프 체크를 하는 것이 매우 바람직한 경우가 있고 @OliverJAsh 의 예와 같이 사용 사이트가 체크되지 않는 외부 코드에 있어서 정의 사이트에서 쉐이프 체크를 해야 하는 경우가 있습니다. .

2번과 관련하여 내가 읽은 많은 게시물에서는 사용 사이트가 충분하기 때문에 모양 확인을 제안합니다. 하지만 사용처가 멀고 먼 은하계 모듈에 있는 경우나.... 사용처가 확인되지 않는 외부 위치에 있는 경우에는 분명히 그렇지 않습니다.

다른 게시물은 정의 사이트에서 모양 확인을 위해 #workarounds 를 제안합니다. 이러한 두려운 해결 방법을 사용하면 정의 사이트에서 모양을 확인할 수 있지만(경우에 따라) 문제가 있습니다.

• 그것들은 위의 1번을 해결하지 못하기 때문에 여전히 모든 클래스의 각 멤버에 대해 명시적으로 형식을 선언해야 합니다.
• 많은 경우 명확성, 우아함 및 가독성이 부족합니다. 항상 사용하기 쉬운 것은 아니며 직관적이지 않으며 가능 여부를 파악하는 데 꽤 오랜 시간이 걸릴 수 있습니다.
• 모든 경우에 작동하는 것은 아니며 #workaroundsToMakeTheWorkaroundsWork 를 찾는 것은 재미도 없고 생산적이지 않지만... 대부분 재미가 없습니다.

다음은 정의 사이트에서 모양 검사를 강제 실행하기 위해 최근에 본 해결 방법의 예입니다...

// (at least) two separate interfaces
interface ISomeComponent { ... }
interface ISomeComponentClass { ... }

// confusing workaround with extra work to use, not very intuitive, etc
export const SomeComponent: ISomeComponentClass =
class SomeComponent extends Component<IProps, IState> implements ISomeComponent {
...
}

이제 던져진 추상 클래스와 함께 그 해결 방법을 사용해보십시오.

interface ISomeComponent { ... }
// need to separate the static type from the class type, because the abstract class won't satisfy
// the shape check for new(): ... 
interface ISomeComponentStatic { ... }
interface ISomeComponentClass { 
    new (): ISomeComponent & ISomeComponentStatic;
}

// I AM ERROR.    ... cannot find name abstract
export const SomeComponentBase: ISomeComponentStatic =
abstract class SomeComponentBase extends Component<IProps, IState> implements ISomeComponent {
...
}

export const SomeComponent: ISomeComponentClass =
class extends SomeComponentBase { ... }

우리도 그 문제를 해결할 것 같아요... 한숨

...

abstract class SomeComponentBaseClass extends Component<IProps, IState> implements ISomeComponent { 
   ... 
}

// Not as nice since we're now below the actual definition site and it's a little more verbose
// but hey at least were in the same module and we can check the shape if the use site is in
// external code...
// We now have to decide if we'll use this work around for all classes or only the abstract ones
// and instead mix and match workaround syntax
export const SomeComponentBase: ISomeComponentStatic = SomeComponentBaseClass;

하지만 잠깐, 더 있습니다! 제네릭을 사용하면 어떻게 되는지 봅시다....

interface IComponent<TProps extends A> { ... }
interface IComponentStatic<TProps extends A> { ... }

interface IComponentClass<TProps extends A, TOptions extends B> extends IComponentStatic<TProps> {
    new (options: TOptions): IComponent<TProps> & IComponentStatic<TProps>;
}

abstract class SomeComponentBaseClass<TProps extends A, TOptions extends B> extends Component<TProps, IState> implements IComponent<TProps> {
...
}

// Ruh Roh Raggy: "Generic type .... requires 2 type argument(s) ..."
export const SomeComponentBase: IComponentStatic = SomeComponentBaseClass;


// "....  requires 1 type argument(s) ... "    OH NO, We need a different workaround
export const SomeComponent: IComponentStatic =
class extends SomeComponentBase<TProps extends A, ISomeComponentOptions> {
...
}

이 시점에서 타이프스크립트로 검사할 코드 내 사용 사이트가 있는 경우 정말 멀리 떨어져 있더라도 총알을 깨물고 그것에 의존해야 합니다.

사이트가 외부인 경우 인터페이스 구성원에 대해 static 수정자를 수락하도록 커뮤니티/유지 관리자를 설득하십시오. 그 동안 다른 해결 방법이 필요합니다. 정의 사이트에는 없지만 #8328에 설명된 해결 방법의 수정된 버전을 사용하여 이를 달성할 수 있다고 생각합니다. 2016년 5월 16일 @RyanCavanaugh 제공 @mhegazy 의 댓글에서 해결 방법을 참조하세요.

요점을 놓치고 있는 경우 용서해 주십시오. 인터페이스 멤버에 대해 static 를 지원하는 것을 주저한다는 사실에 대한 나의 이해는 기본적으로 동일한 인터페이스 + 구현 키워드를 사용하여 생성자의 모양과 인스턴스의 모양을 모두 설명하는 것을 싫어한다는 것입니다.

나는 typescript가 제공하는 것을 사랑하고 그것을 개발한 사람들과 과다한 기능 요청을 처리하기 위해 많은 생각과 노력을 기울이는 커뮤니티에 크게 감사한다는 말로 다음 비유를 시작하겠습니다. 잘 맞는 기능을 구현하기 위해 최선을 다합니다.

그러나 이 경우의 주저함은 사용성을 희생하면서 '개념적 순수성'을 유지하려는 욕망으로 보인다. 이 비유가 기본이 아닌 경우 다시 한 번 죄송합니다.

이것은 Java 에서 C# 로 전환하는 것을 상기시켰습니다. 이 작업을 수행하는 C# 코드를 처음 보았을 때
C# var something = "something"; if(something == "something") { ... }
알람 벨이 내 머리에서 울리기 시작했고, 세상은 끝나가고 있었고, "something".Equals(something) 등을 사용해야 했습니다.

== 는 참조용입니다. 문자열 비교를 위해 별도의 .Equals(...) 가 있습니다...
그리고 문자열 리터럴이 먼저 와야 하므로 null 변수에 대해 .Equals(...)를 호출하는 null ref를 얻지 못합니다...
그리고... 그리고... 과호흡

그리고 몇 주 동안 C# 를 사용한 후 그 동작으로 인해 사용하기가 훨씬 더 쉽다는 것을 깨달았습니다. 둘 사이의 명확한 구분을 포기하는 것을 의미했지만 그만한 가치가 있는 사용성을 극적으로 향상시킵니다.

이것이 인터페이스 멤버에 대한 static 수식어에 대한 느낌입니다. 그것은 우리가 이미 하고 있는 것처럼 인스턴스의 모양을 계속 설명할 수 있게 해주고, 사례별로 좋지 않은 해결 방법으로만 할 수 있는 생성자 함수의 모양을 설명할 수 있게 해주며, 상대적으로 깨끗하고 쉬운 두 가지 모두를 수행할 수 있게 해줍니다. 방법. 사용 편의성이 크게 향상되었습니다. IMO.

다음 댓글에서 abstract static 에 무게를 싣겠습니다....

인터페이스는 항상 클래스를 구현할 때 멤버 유형을 다시 지정해야 합니다. (클래스를 구현하는 _명시적으로_ 멤버 서명의 추론은 아직 지원되지 않는 별도의 기능입니다).

오류가 발생하는 이유는 이 제안과 관련이 없습니다. 이 문제를 해결하려면 정적 또는 기타 리터럴 유형이어야 하는 클래스 멤버의 구현에 readonly 수정자를 사용해야 합니다. 그렇지 않으면 string 가 유추됩니다.

다시 implements 키워드는 의도의 사양일 뿐이며 유형의 구조적 호환성에 영향을 미치거나 명목 유형을 도입하지 않습니다. 유용하지 않다는 것은 아니지만 유형을 변경하지는 않습니다.

그래서 abstract static ... 가치가 없습니다. 문제가 너무 많습니다.

암시적으로 사용 사이트에서 이미 검사할 내용을 선언하려면 새롭고 복잡한 구문이 필요합니다(사용 사이트가 typescript 컴파일러에 의해 검사되는 경우).

사용 사이트가 외부인 경우 실제로 필요한 것은 인터페이스의 static 구성원입니다... 죄송합니다 연결 완료.... 그리고 좋은 밤입니다!

@aluanhaddad 사실이지만 명시적으로 구현하는 클래스에서 멤버 서명의 추론이 지원되는 기능이라고 해도 클래스의 정적 측면에 대한 멤버 서명을 선언하는 명확한 방법이 부족합니다.

내가 표현하려고 했던 요점은 우리가 explicitly 클래스의 정적 측면의 예상 구조를 선언할 방법이 없고 그것이 중요한 경우가 있다는 것입니다(또는 기능을 지원하기 위해 중요할 경우)

주로 "클래스의 정적 측면에 대한 요구 사항을 지정하는 인터페이스가 구문적으로 참조되는지 여부는 중요하지 않습니다"라는 귀하의 의견에서 이 부분을 반박하고 싶었습니다.

나는 유형 추론을 향후 지원에서 중요한 이유 에 대한 예로 사용하려고 했습니다.
여기서 인터페이스를 구문적으로 참조하면 let something: ISomethingStatic = { isFlammable: 'Ys', isFlammable2: 'No' ... isFlammable100: 'No' } 유형을 명시적으로 'Yes'로 선언할 필요가 없습니다. '아니요' 100번 별도입니다.

클래스의 정적 측면에 대해 동일한 유형 추론을 달성하려면(향후) 인터페이스를 구문적으로 참조하는 방법이 필요합니다.

귀하의 최신 의견을 읽은 후 제가 기대했던 것만큼 명확한 예가 아니라고 생각합니다. 아마도 더 나은 예는 클래스의 정적 측면에 대한 사용 사이트가 typescript 컴파일러에서 확인하지 않는 외부 코드에 있는 경우일 것입니다. 이러한 경우 우리는 현재 본질적으로 인위적인 사용 사이트를 만들고 사용성/가독성이 좋지 않으며 많은 경우에 작동하지 않는 해결 방법에 의존해야 합니다.

약간의 장황함을 희생시키면서 적절한 수준의 유형 안전성을 얻을 수 있습니다.

type HasType<T, Q extends T> = Q;

interface IStatic<X, Y> {
    doWork: (input: X) => Y
}

type A_implments_IStatic<X, Y> = HasType<IStatic<X, Y>, typeof A>    // OK
type A_implments_IStatic2<X> = HasType<IStatic<X, number>, typeof A> // OK
type A_implments_IStatic3<X> = HasType<IStatic<number, X>, typeof A> // OK
class A<X, Y> {
    static doWork<T, U>(_input: T): U {
        return null!;
    }
}

type B_implments_IStatic = HasType<IStatic<number, string>, typeof B> // Error as expected
class B {
    static doWork(n: number) {
        return n + n;
    }
}

이를 허용해야 한다는 데 동의했습니다. 다음과 같은 간단한 사용 사례는 추상 정적 메서드의 이점을 얻을 수 있습니다.

export abstract class Component {
  public abstract static READ_FROM(buffer: ByteBuffer): Component;
}

// I want to force my DeckComponent class to implement it's own static ReadFrom method
export class DeckComponent extends Component {
  public cardIds: number[];

  constructor(cardIds: number[]) {
    this.cardIds = cardIds;
  }

  public static READ_FROM(buffer: ByteBuffer): DeckComponent {
    const cardIds: number[] = [...];
    return new DeckComponent(cardIds);
  }
}

@RyanCavanaugh 나는 아무도 이것을 아직 정확하게 언급하지 않았다고 생각합니다(빠른 읽기에서 놓칠 수 있지만). 그러나 이에 대한 응답은 다음과 같습니다.

이것을 고려할 때 우리가 가진 주요 질문: 추상 정적 메서드를 호출할 수 있는 사람은 누구입니까? 아마도 AbstractParentClass.getSomeClassDependentValue를 직접 호출할 수 없을 것입니다. 그러나 AbstractParentClass 유형의 표현식에서 메소드를 호출할 수 있습니까? 그렇다면 왜 허용되어야 합니까? 그렇지 않은 경우 기능의 용도는 무엇입니까?

이것은 #3841의 일부를 구현하여 해결할 수 있습니다. 그 문제를 읽으면서 제기된 주된 반대는 파생 클래스의 생성자 함수 유형이 기본 클래스의 생성자 함수와 호환되지 않는 경우가 많다는 것입니다. 그러나 TypeScript는 재정의된 정적 항목이 기본 클래스의 해당 형식과 호환되는지 이미 확인하고 있기 때문에 다른 정적 메서드나 필드에는 동일한 문제가 적용되지 않는 것으로 보입니다.

그래서 제가 제안하고 싶은 것은 T.constructor Function & {{ statics on T }} 유형을 제공하는 것입니다. 그러면 abstract static foo 필드를 선언하는 추상 클래스가 생성자 비호환성 문제를 일으키지 않으면서 this.constructor.foo 를 통해 안전하게 액세스할 수 있습니다.

그리고 T.constructor 에 자동으로 statics를 추가하는 것이 구현되지 않더라도 "constructor": typeof AbstractParentClass 를 수동으로 선언하여 기본 클래스에서 abstract static 속성을 계속 사용할 수 있습니다.

많은 사람들이 @patryk-zielinski93 예제 가 작동해야 한다고 생각합니다. 대신 우리는 직관적이지 않고 장황하고 비밀스러운 해결 방법을 사용해야 합니다. 우리는 이미 'syntax sugared' 클래스와 정적 멤버를 가지고 있기 때문에 유형 시스템에 그러한 설탕을 가질 수 없는 이유는 무엇입니까?

내 고통은 다음과 같습니다.

abstract class Shape {
    className() {
        return (<typeof Shape>this.constructor).className;
    }
    abstract static readonly className: string; // How to achieve it?
}

class Polygon extends Shape {
    static readonly className = 'Polygon';
}

class Triangle extends Polygon {
    static readonly className = 'Triangle';
}

대신/병렬로 static implements 절을 도입할 수 있습니까? 예

interface Foo {
    bar(): number;
}

class Baz static implements Foo {
    public static bar() {
        return 4;
    }
}

이것은 내가 이 스레드를 올바르게 읽고 있다면 현재 선택 가능한 해결 방법인 것처럼 보이는 정적 및 인스턴스 멤버에 대해 별도의 인터페이스를 선언하는 것과 이전 버전과 호환된다는 이점이 있습니다. 그것은 또한 그 자체로 유용하다고 볼 수 있는 미묘하게 다른 기능이지만, 그것은 요점을 벗어납니다.

( statically implements 가 더 나을 수 있지만 새 키워드를 도입하는 것입니다. 이것이 가치가 있는지 논쟁의 여지가 있습니다. 하지만 상황에 따라 달라질 수 있습니다.)

OP의 제안에 회의적인 사람들의 주장을 이해하려고 아무리 애를 써도 나는 실패했다.

한 사람(https://github.com/Microsoft/TypeScript/issues/14600#issuecomment-379645122)만 @RyanCavanaugh 에 답변했습니다. OP의 코드를 다시 작성하여 좀 더 깔끔하게 만들고 귀하의 질문과 답변을 설명했습니다.

abstract class Base {
  abstract static foo() // ref#1
}

class Child1 extends Base {
  static foo() {...} // ref#2
}

class Child2 extends Base {
  static foo() {...}
}

추상 정적 메서드를 호출할 수 있는 사람은 누구입니까? 아마도 Base.foo 를 직접 호출할 수 없습니다.

ref # 1을 의미한다면 네, 호출 가능해서는 안됩니다. 왜냐하면 그것은 추상적이고 본문도 없기 때문입니다.
ref#2만 호출할 수 있습니다.

그러나 Base 유형의 표현식에서 메소드를 호출할 수 있습니까?
그렇다면 왜 허용되어야 합니까?

function bar(baz:Base) { // "expression of type Base"
  baz.foo() // ref#3
}

function bar2(baz: typeof Base) { // expression of type Base.constructor
  baz.foo() // ref#4
}

ref # 3은 오류입니다. 아니요, baz 는 Child1 또는 Child2의 __instance__여야 하고 인스턴스에는 정적 메서드가 없기 때문에 "foo"를 호출할 수 없습니다.

ref#4는 (반드시) 정확합니다. baz 는 Base를 확장하고 따라서 foo()를 구현해야 하는 Child1 또는 Child2의 생성자로 간주되기 때문에 정적 메서드 foo를 호출할 수 있습니다(할 수 있어야 함).

bar2(Child1) // ok
bar2(Child2) // ok

다음과 같은 상황을 상상할 수 있습니다.

bar2(Base) // ok, but ref#4 should be red-highlighted with compile error e.g. "Cannot call abstract  method." 
// Don't know if it's possible to implement in compiler, though. 
// If not, compiler simply should not raise any error and let JS to do it in runtime (Base.foo is not a function). 

기능의 용도는 무엇입니까?

참조 #4를 참조하십시오. 인수로 받은 자식 클래스 중 하나(Child1 또는 Child2일 수 있음)를 알지 못하지만 정적 메서드를 호출하고 해당 메서드가 있는지 확인하려는 경우에 사용합니다.
나는 AdonisJS라고 불리는 node.js 프레임워크를 다시 작성하고 있습니다. 순수 JS로 작성되었으므로 TS로 변환합니다. 코드 작동 방식을 변경할 수 없으며 유형만 추가하고 있습니다. 이 기능이 없다는 것은 저를 매우 슬프게 만듭니다.

ps 이 주석에서는 단순성을 위해 추상 클래스에 대해서만 썼고 인터페이스는 언급하지 않았습니다. 하지만 내가 쓴 모든 것은 인터페이스에 적용할 수 있습니다. 추상 클래스를 인터페이스로 바꾸기만 하면 모든 것이 정확할 것입니다. 어떤 이유로 TS 팀이 abstract static in abstract class 를 구현하지 않으려는 경우(이유를 모름) 가능성이 있지만 static 만 구현하는 것이 좋습니다. 우리를 충분히 행복하게 만들 것입니다.

pps 내 코드를 준수하기 위해 질문에서 클래스 및 메서드 이름을 편집했습니다.

다른 회의론자들의 주요 주장에 근거한 몇 가지 생각:

"아니요, 이것은 구현해서는 안 되지만 이미 이렇게 할 수 있습니다. *15배 더 많은 코드 줄을 작성*".

그것이 구문 설탕이 만들어지는 것입니다. TS에 약간(설탕)을 추가합시다. 그러나 아니요, 인터페이스에 간단한 static 단어를 추가하는 대신 데코레이터와 수십 개의 제네릭을 돌파하려는 개발자의 두뇌를 고문하는 것이 좋습니다. static 를 우리의 삶을 더 쉽게 만드는 또 다른 설탕으로 생각하지 않으시겠습니까? ES6과 같은 방식으로 class 를 추가합니다(요즘 유비쿼터스 상태가 됨). 그러나 아니요, 우리는 괴상한 사람이 되어 오래되고 "올바른" 방식으로 일을 합시다.

"js 클래스에는 생성자와 인스턴스의 두 가지 인터페이스가 있습니다."

자, 그렇다면 생성자를 위한 인터페이스를 만드는 방법을 제공하지 않으시겠습니까? 그러나 단순히 static 단어를 추가하는 것이 훨씬 쉽고 직관적입니다.

그리고 이것에 관하여:

더 많은 피드백이 들릴 때까지 보류합니다.

이 문제가 언제까지 보류될 예정인지 1년 이상이 지났고 많은 피드백이 제공되었습니다. 누가 대답 좀 해주세요.

이 게시물은 다소 거칠게 보일 수 있습니다. 하지만 아니요, 그것은 TS를 사랑하는 사람의 요청이며 동시에 우리가 오래된 JS 코드베이스를 TS로 변환할 때 못생긴 핵을 사용해야 하는 확실한 이유를 찾을 수 없습니다. 이 외에도 TS팀에 감사드립니다. TS는 정말 훌륭하고 제 인생을 바꿔놓았고 저는 그 어느 때보다 코딩과 제 직업을 즐깁니다... 하지만 이 문제가 제 경험을 망치고 있습니다..

가능한 해결 방법?

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

declare global {
  interface Function extends StaticInterface {
  }
}

export interface StaticInterface {
  builder: (this: Constructor<MyClass>) => MyClass
}

// TODO add decorator that adds "builder" implementation
export class MyClass {
  name = "Ayyy"
}

export class OtherClass {
  id = "Yaaa"
}

MyClass.builder() // ok
OtherClass.builder() // error

제안: 인터페이스 및 유형의 정적 멤버 및 추상 클래스의 추상 멤버, v2

사용 사례

Fantasyland 호환 유형

````타이프스크립트
인터페이스 적용 확장 적용 {(a: A)의 정적 : 적용 ; }

const of = >(c: C, a: A): new C => c.of(a); ````

Serializable 정적 deserialize 메서드가 있는 유형

````타이프스크립트
인터페이스 직렬화 가능 {
정적 역직렬화(들: 문자열): 직렬화 가능;

serialize(): string;

}
````

일반 계약

````타이프스크립트
인터페이스 계약 {
정적 생성(x: 숫자): 계약;
static new(x: 숫자): 계약;
}

const factory1 = (c: 정적 계약): 계약 => c.create(Math.random());
const factory2 = (C: 정적 계약): 계약 => new C(Math.random());
상수 공장3 =(c: C): new C => c.create(Math.random());

const c1 = 공장1(ContractImpl); // Contract
const c2 = 공장2(ContractImpl); // Contract
const c3 = 공장3(ContractImpl); // ContractImpl
````

통사론

정적 메서드 및 필드

````타이프스크립트
인터페이스 직렬화 가능 {
정적 역직렬화(들: 문자열): 직렬화 가능;
}

유형 직렬화 가능 = {
정적 역직렬화(들: 문자열): 직렬화 가능;
};

추상 클래스 직렬화 가능 {
정적 추상 역직렬화(들: 문자열): 직렬화 가능;
}
````

정적 생성자 서명

typescript interface Contract { static new(): Contract; }

후속 조치: 정적 호출 서명

논의하다:

정적 호출 서명은 어떻게 표현될 수 있습니까?
호출 서명 앞에 static 수식어를 추가하여 간단히 표현하자면,
이름이 'static' 인 인스턴스 메소드와 어떻게 구별합니까?
'new' -named 메서드와 동일한 해결 방법을 사용할 수 있습니까?
그런 경우에는 확실히 획기적인 변화가 될 것입니다.

static 유형 연산자

typescript const deserialize = (Class: static Serializable, s: string): Serializable => Class.deserialize(s);

new 유형 연산자

typescript const deserialize = <C extends static Serializable>(Class: C, s: string): new C => Class.deserialize(s);

내부 슬롯

[[Static]] 내부 슬롯

유형의 "정적" 인터페이스는 [[Static]] 내부 슬롯에 저장됩니다.

````타이프스크립트
// 유형
인터페이스 직렬화 가능 {
정적 역직렬화(들: 문자열): 직렬화 가능;
직렬화: 문자열;
}

// 내부적으로 다음과 같이 표현됩니다.
// 인터페이스 직렬화 가능 {
// [[정적]]: {
// [[인스턴스]]: 직렬화 가능; // 아래를 참조하십시오.
// 역직렬화(들: 문자열): 직렬화 가능;
// };
// 직렬화(): 문자열;
// }
````

기본적으로 never 유형이 있습니다.

[[Instance]] 내부 슬롯

유형의 "인스턴스" 인터페이스가 저장됩니다.
[[Instance]] [[Static]] 내부 슬롯.

기본적으로 never 유형이 있습니다.

의미론

static 연산자 없이

타입이 값 타입으로 사용될 때,
[[Static]] 내부 슬롯이 삭제됩니다.

````타이프스크립트
const 직렬화 선언: 직렬화 가능;

유형 T = 직렬화 가능한 유형;
// { 직렬화(): 문자열; }
````

그러나 유형 자체는 [[Static]] 내부 슬롯을 유지합니다.

typescript type T = Serializable; // { // [[Static]]: { // [[Instance]]: Serializable; // deserialize(s: string): Serializable; // }; // serialize(): string; // }

할당 가능성

정적 인식 유형의 두 값은 구조적으로 동일한
(물론 [[Static]] 제외) 1과 그 반대도 마찬가지입니다.

static 연산자

| 연관성 | 우선 순위 |
| :-------------: | :--------------------------------: |
| 오른쪽 | IDK이지만 new 의 것과 같음 |

static 유형 연산자는 유형의 [[Static]] 내부 슬롯 유형을 반환합니다.
typeof 유형 연산자와 다소 유사합니다.
그러나 인수는 값이 아니라 유형이어야 합니다.

typescript type T = static Serializable; // { // [[Instance]]: Serializable; // deserialize(s: string): Serializable; // }

typeof 유형 연산자는 [[Instance]] 내부 슬롯도 버립니다.

````타이프스크립트
const SerializableImpl 선언: 정적 직렬화 가능;

유형 T = 직렬화 가능Impl 유형;
// { deserialize(s: string): 직렬화 가능; }
````

할당 가능성

인스턴스 인식 유형의 두 값은 구조적으로 동일한
(물론 [[Instance]] 내부 슬롯 제외) 슬롯과 그 반대의 경우도 마찬가지입니다.

new 연산자

| 연관성 | 우선 순위 |
| :-------------: | :-------------------------------------------------: |
| 오른쪽 | IDK, 그러나 static 의 것과 같음 |

new 연산자는 해당 유형의 [[Instance]] 내부 슬롯 유형을 반환합니다.
static 연산자를 효과적으로 반대로 합니다.

typescript type T = new static Serializable; // { // [[Static]]: { // [[Instance]]: Serializable; // deserialize(s: string): Serializable; // }; // serialize(): string; // }

extends / implements 의미론

기본이 아닌 [[Static]] 내부 슬롯이 있는 인터페이스를 구현하는 클래스
호환되는 [[Static]] 내부 슬롯이 있어야 합니다.
호환성 검사는 다음과 동일하거나 유사해야 합니다.
정기적(인스턴스) 호환성 검사.

````타이프스크립트
클래스 SerializableImpl은 Serializable {를 구현합니다.
정적 역직렬화(들: 문자열): SerializableImpl {
// 역직렬화 논리가 여기에 있습니다.
}

// ...other static members
// constructor
// ...other members

serialize(): string {
    //
}

}
````

할 것

• [ ] 정적 호출 서명에 사용할 구문을 결정합니다.
  변경 사항을 중단하지 않고 가능합니다.
• [ ] 조건부 유형과 infer 연산자에 특별한 경우가 있습니까?
• [ ] 비추상 클래스 멤버의 의미를 변경합니다. _깨질 수도 있습니다._

이 문제와 내 문제에 대한 해결 방법에 대한 다른 문제를 읽는 데 몇 시간을 보냈습니다. 이 문제는 정적 수정자 또는 클래스용 인터페이스로 해결할 수 있습니다. 내 문제를 해결하는 단일 해결 방법을 찾을 수 없습니다.

내가 가진 문제는 코드 생성 클래스를 수정하고 싶다는 것입니다. 예를 들어 내가 하고 싶은 일은 다음과 같습니다.

import {Message} from "../protobuf";

declare module "../protobuf" {
    interface Message {
        static factory: (params: MessageParams) => Message
    }
}

Message.factory = function(params: MessageParams) {
    const message = new Message();
    //... set up properties
    return message;
}

export default Message;

현재 버전의 TS에서 이와 동등한 작업을 수행할 수 있는 단일 해결 방법을 찾을 수 없습니다. 현재 이 문제를 해결할 방법을 놓치고 있습니까?

이것은 분명히 해결 방법이 없고 직접적인 해결 방법이 없는 사용 사례로 여기에 게시하는 것과 관련이 있습니다.

인터페이스에 대해 클래스의 인스턴스 및 정적 측면을 확인하려면 다음과 같이 할 수 있습니다.

interface C1Instance {
  // Instance properties ...

  // Prototype properties ...
}
interface C2Instance extends C1Instance {
  // Instance properties ...

  // Prototype properties ...
}

interface C1Constructor {
  new (): C1Instance;

  // Static properties ...
}
interface C2Constructor {
  new (): C2Instance;

  // Static properties ...
}

type C1 = C1Instance;
let C1: C1Constructor = class {};

type C2 = C2Instance;
let C2: C2Constructor = class extends C1 {};

let c1: C1 = new C1();
let c2: C2 = new C2();

우리 중 너무 많은 사람들이 이것에 너무 많은 시간과 다른 사람들을 낭비하고 있습니다. 왜 그게 아니지?!?i!
읽을 수 있고 소화할 수 있어야 하며 간단한 1줄 내용에 대한 답변이 모두 거대한 해결 방법인 이유는 무엇입니까? 누군가가 내 코드가 해키 해결 방법으로 무엇을 하려고 하는지 알아내도록 하는 방법은 없습니다. 별로 가치가 없는 일로 이 주제를 더 복잡하게 만들어서 죄송합니다. 하지만 현재로서는 엄청난 고통과 시간 낭비입니다. 그래서 저는 그것이 저와 지금의 다른 사람들, 그리고 나중에 답을 찾는 사람들에게 가치가 있다는 것을 알게 되었습니다.

자연어와 인공 언어를 막론하고 어떤 언어든 자연스럽게 진화하여 효율적이고 매력적으로 사용되어야 합니다. 결국 사람들은 언어의 감소("oky"=>"ok","going to" =>"gonna")를 사용하기로 결정하고 "selfie" 및 "google"과 같은 새로운 우스꽝스러운 단어를 발명하고 l33tspeak로 철자를 재정의했으며 심지어 일부 단어를 금지하기도 했습니다. 사용을 원하든 원하지 않든, 모두는 여전히 그 의미를 어느 정도 이해하고 있으며 우리 중 일부는 특정 작업을 수행하기 위해 사용합니다. 그리고 그들 중 누구도 정당한 이유가 있을 수 없지만 특정 작업에서 특정 사람들의 효율성은 모두 실제로 그들을 사용하는 사람들의 수의 문제입니다. 이 대화의 양을 보면 많은 사람들이 이 static abstract 를 어떤 빌어먹을 고려 사항에 사용할 수 있음을 분명히 알 수 있습니다. 나는 같은 이유로 여기에 왔습니다. Serializable 를 구현하고 싶었기 때문에 직관적인 (저를 위해) 모든 방법을 시도했지만 그 중 아무 것도 작동하지 않았습니다. 저를 믿으세요. 제가 마지막으로 찾는 것은 왜 이 기능이 필요하지 않고 다른 것으로 가야 하는지에 대한 설명입니다. 일년 반, 예수 그리스도! 이미 어딘가에 테스트와 자료가 있는 PR이 있을 것입니다. 이것을 가능하게 하고, 권장하지 않는 특정 사용 방법이 있는 경우 이를 위한 tslint가 있습니다.

this.constructor.staticMember 를 통해 기본 클래스에서 자식 클래스의 정적 멤버에 액세스할 수 있으므로 추상 정적 멤버가 이해가 됩니다.

class A {
  f() {
    console.log(this.constructor.x)
  }
}

class B extends A {
  static x = "b"
}

const b = new B
b.f() // logs "b"

클래스 A는 f 메서드에서 사용하기 때문에 정적 x 멤버가 필요하다고 지정할 수 있어야 합니다.

어떤 소식이 있습니까?
기능은 정말 필요합니다 😄
1) 인터페이스 의 static 함수
2) 추상 클래스 의 abstract static 함수

정적 인터페이스가 있다는 아이디어는 싫지만 모든 실용적인 목적을 위해 오늘 은 다음으로 충분합니다.

type MyClass =  (new (text: string) => MyInterface) & { myStaticMethod(): string; }

다음과 같이 사용할 수 있습니다.

const MyClass: MyClass = class implements MyInterface {
   constructor(text: string) {}
   static myStaticMethod(): string { return ''; }
}

업데이트:

아이디어 및 실제 예 에 대한 자세한 내용:

// dynamic part
interface MyInterface {
    data: number[];
}
// static part
interface MyStaticInterface {
    myStaticMethod(): string;
}

// type of a class that implements both static and dynamic interfaces
type MyClass = (new (data: number[]) => MyInterface) & MyStaticInterface;

// way to make sure that given class implements both 
// static and dynamic interface
const MyClass: MyClass = class MyClass implements MyInterface {
   constructor(public data: number[]) {}
   static myStaticMethod(): string { return ''; }
}

// works just like a real class
const myInstance = new MyClass([]); // <-- works!
MyClass.myStaticMethod(); // <-- works!

// example of catching errors: bad static part
/*
type 'typeof MyBadClass1' is not assignable to type 'MyClass'.
  Type 'typeof MyBadClass1' is not assignable to type 'MyStaticInterface'.
    Property 'myStaticMethod' is missing in type 'typeof MyBadClass1'.
*/
const MyBadClass1: MyClass = class implements MyInterface {
   constructor(public data: number[]) {}
   static myNewStaticMethod(): string { return ''; }
}

// example of catching errors: bad dynamic part
/*
Type 'typeof MyBadClass2' is not assignable to type 'MyClass'.
  Type 'typeof MyBadClass2' is not assignable to type 'new (data: number[]) => MyInterface'.
    Type 'MyBadClass2' is not assignable to type 'MyInterface'.
      Property 'data' is missing in type 'MyBadClass2'.
*/
const MyBadClass2: MyClass = class implements MyInterface {
   constructor(public values: number[]) {}
   static myStaticMethod(): string { return ''; }
}

@aleksey-bykov 이것은 Typescript의 잘못이 아닐 수도 있지만 작동하는 Angular 구성 요소 데코레이터와 AoT 컴파일러를 얻을 수 없습니다.

@aleksey-bykov 영리하지만 여전히 추상 정적에서는 작동하지 않습니다. MyClass 의 하위 클래스가 있는 경우 유형 검사가 적용되지 않습니다. 제네릭이 관련된 경우에도 더 나쁩니다.

// no errors
class Thing extends MyClass {

}

정적 속성을 요구하는 최종 사용자 라이브러리를 구축하는 것은 합리적인 구현이 없기 때문에 TypeScript 팀이 이에 대한 입장을 재고하기를 정말로 바랍니다. 인터페이스 구현자/추상 클래스 확장자에 정적 속성이 있어야 하는 계약을 가질 수 있어야 합니다.

@bbugh 여기서 논의되는 문제의 존재 자체에 의문을 제기합니다. 일반 클래스의 인스턴스를 통해 동일한 작업을 수행할 수 있다면 정적 추상 상속 메서드에 이러한 모든 문제가 필요한 이유는 무엇입니까?

class MyAbstractStaticClass {
    abstract static myStaticMethod(): void; // <-- wish we could
}
class MyStaticClass extends MyAbstractStaticClass {
    static myStaticMethod(): void {
         console.log('hi');
    }
}
MyStaticClass.myStaticMethod(); // <-- would be great

대

class MyAbstractNonStaticClass {
    abstract myAbstractNonStaticMethod(): void;
}
class MyNonStaticClass extends MyAbstractNonStaticClass {
    myNonStaticMethod(): void {
        console.log('hi again');
    }
}
new MyNonStaticClass().myNonStaticMethod(); // <-- works today

@aleksey-bykov 많은 이유가 있습니다. 예를 들어(@patryk-zielinski93 에서 ):

abstract class Serializable {  
    abstract serialize (): Object;  
    abstract static deserialize (Object): Serializable;  
}  

Serializable의 하위 클래스에서 정적 역직렬화 메서드를 강제로 구현하고 싶습니다.
그러한 동작을 구현하기 위한 해결 방법이 있습니까?

편집: deserialize 를 생성자로 사용할 수도 있다는 것을 알고 있지만 클래스에는 팩토리 메서드가 필요한 생성자가 1개만 있을 수 있습니다. 사람들은 인터페이스에서 팩토리 메소드를 요구하는 방법을 원하는데, 이는 완전히 의미가 있습니다.

역직렬화되는 바로 그 클래스에 정적 역직렬화 메소드를 첨부하는 이점이 없기 때문에 단순히 욕구화 논리를 별도의 클래스로 가져갑니다.

class Deserializer {
     deserializeThis(...): Xxx {}
     deserializeThat(...): Yyy {}
}

무엇이 문제인가?

@aleksey-bykov 별도의 클래스가 예쁘지 않습니다.

@aleksey-bykov, 문제는 직렬화가 필요한 클래스가 2개 이상 있다는 것입니다. 따라서 귀하의 접근 방식은 uberclass 반패턴인 직렬화 사전을 만드는 방향으로 강제되고 있으며 이들 중 하나를 수정할 때마다 이 uberclass에서 편집이 필요합니다. 코드 지원을 귀찮게 만듭니다. 직렬화 가능한 인터페이스가 있으면 주어진 객체 유형에 대한 구현을 강제할 수 있지만 사람들이 원하는 주요 이유인 다형성 상속도 지원합니다. 혜택이 있는지 없는지 추측하지 마십시오. 누구나 선택권이 있고 자신의 프로젝트에 유익한 것을 선택할 수 있어야 합니다.

@octaharon 은 역직렬화 전용 클래스를 갖는 것은 당신이 말한 것과 정반대이며, 역직렬화에 대해 신경을 쓸 때만 변경하기 때문에 단일 책임이 있습니다.

반대로 당신이 제안한 것처럼 클래스 자체에 역직렬화를 추가하면 추가 책임과 변경 이유가 추가됩니다.

마지막으로 정적 메서드에는 문제가 없지만 추상 정적 메서드 및 정적 인터페이스에 대한 실제 사용 사례를 보고 싶어 정말 궁금합니다.

@octaharon 은 역직렬화 전용 클래스를 갖는 것은 당신이 말한 것과 정반대이며, 역직렬화에 대해 신경을 쓸 때만 변경하기 때문에 단일 책임이 있습니다.

(비)직렬화는 유형 구조에 따라 다르므로 한 곳이 아닌 두 곳에서 코드를 변경해야 한다는 점을 제외하고. 이는 "단일 책임"에 포함되지 않습니다.

반대로 당신이 제안한 것처럼 클래스 자체에 역직렬화를 추가하면 추가 책임과 변경 이유가 추가됩니다.

나는 당신이 말하는 것을 이해하지 못합니다. 자체 (역)직렬화를 담당하는 클래스가 정확히 내가 원하는 것이므로 옳고 그름을 말하지 마십시오.

단일 책임은 관련된 파일 수에 대해 아무 것도 말하지 않고 단일 이유만 있어야 한다고 말합니다.

내가 말하려는 것은 새 클래스를 추가할 때 단순히 역직렬화되는 것이 아닌 다른 것을 의미하므로 이미 존재하는 이유와 그에 할당된 책임이 있다는 것입니다. 그런 다음 자체를 역직렬화할 수 있는 또 다른 책임을 추가합니다. 이것은 우리에게 2가지 책임을 부여합니다. 이것은 SOLID를 위반합니다. 렌더링, 인쇄, 복사, 전송, 암호화 등과 같은 더 많은 것을 계속 추가하면 신 클래스를 얻게 됩니다.

진부한 말을 해서 죄송합니다. 하지만 이점과 실제 사용 사례에 대한 질문(및 답변)이 이 기능 제안을 구현하게 만드는 원동력입니다.

SOLID는 전능하신 하나님께서 태블릿으로 보내신 것이 아니며, 있다고 하더라도 해석의 자유도가 있습니다. 당신은 당신이 그것에 대해 원하는 만큼 이상주의적일 수 있지만, 제게 부탁을 들어 주십시오. 당신의 믿음을 지역 사회에 퍼뜨리지 마십시오. 모든 사람은 원하는 방식으로 모든 도구를 사용하고 그가 알고 있는 모든 가능한 규칙을 위반할 수 있는 모든 권리가 있습니다(살인에 대해 칼을 비난할 수는 없습니다). 도구의 품질을 정의하는 것은 특정 기능에 대한 수요와 그에 대한 제안 간의 균형입니다. 그리고 이 분기는 수요량을 보여줍니다. 이 기능이 필요하지 않다면 사용하지 마십시오. 그렇다. 그리고 여기 있는 많은 사람들도 그것을 필요로 하고 _우리는_ 실용적인 사용 사례를 가지고 있지만 실제로는 우리가 그것을 무시해야 한다고 말하고 있습니다. 그것은 유지자들에게 더 중요한 것, 즉 신성한 원칙(그들이 이해하는 방식에 상관없이) 또는 커뮤니티에 관한 것입니다.

어떤 좋은 제안은 사용 사례를 제공하지만 이 제안은

그래서 나는 단지 약간의 호기심을 표현하고 질문을 했습니다. 제안서에는 그것을 말하지 않기 때문에, 왜 사람들이 그것을 필요로 하는지

그것은 전형적인 것으로 요약됩니다. 정당한 이유, 감히하지 마십시오

개인적으로 나는 solid 또는 oop에 대해 신경 쓰지 않습니다. 나는 오래전에 우연히 그것을 과도하게 성장시켰습니다. 당신은 "uberclass antipattern" 논쟁을 던지고 나서 그것을 "해석에 대한 자유도"로 뒷받침했습니다.

이 전체 토론에서 언급된 유일한 실질적인 이유는 다음과 같습니다. https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -308362119

이것이 도움이 될 매우 일반적인 사용 사례는 displayName, propTypes 및 defaultProps와 같은 정적 속성이 있는 클래스인 React 구성 요소입니다.

및 몇 가지 게시물 유사 https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -345496014

하지만 (new (...) => MyClass) & MyStaticInterface 로 덮여 있습니다.

그것이 정확한 사용 사례이자 내가 여기에 있는 이유입니다. 투표수 보이시나요? 무엇이 practical 이고 무엇이 아닌지 결정하는 것이 왜 개인적으로 귀하에게 달려 있다고 생각합니까? Practical 는 practice 에 넣을 수 있는 것입니다. (글을 쓰는 시점에서) 83명이 이 기능이 정말 실용적이라고 생각할 것입니다. 다른 사람들을 존중하고 문맥에서 문구를 꺼내고 다양한 유행어를 보여주기 전에 전체 스레드를 읽으십시오. 당신이 극복한 것이 무엇이든, 그것은 확실히 당신의 에고가 아닙니다.

실용적인 것은 문제를 해결하는 것이고, 비실용적인 것은 당신의 미감을 자극하는 것이라는 것은 상식입니다. 저는 다른 사람들을 존중합니다. https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -308362119 및 https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -289084844에 대해 주어진 (new (...) => MyClass) & MyStaticInterface 를 해결하십시오.

대답하지 말아주세요

같은 이유로 나는 때때로 큰 주석을 줄이기 위해 type 선언을 사용합니다 abstract static 와 같은 키워드는 기존에 언급된 것처럼 상대적으로 소화하기 어려운 구문보다 훨씬 읽기 쉽습니다. 예시.

게다가 아직 추상 클래스를 다루지 않았습니까?

내 생각에는 추상 클래스를 사용하지 않는 솔루션이 솔루션이 아닙니다. 그것은 해결 방법입니다! 해결 방법은 무엇입니까?

이 기능 요청은 요청자를 포함한 많은 사람들이 인터페이스에 abstract static 또는 static 와 같은 예상 기능이 존재하지 않는다는 것을 발견했기 때문에 존재한다고 생각합니다.

제공된 솔루션에 따라 static 키워드가 사용되지 않도록 하는 해결 방법이 있는 경우에도 존재해야 합니까? 제안하는 것도 마찬가지로 어리석은 일이라고 생각합니다.

여기서 문제는 static 가 훨씬 더 합리적이라는 것입니다.
생성된 관심을 바탕으로 덜 무시하는 토론을 할 수 있습니까?

이 제안에 대한 업데이트가 있습니까? static abstract 등이 없어야 하는 이유를 설명할 가치가 있는 인수가 있습니까?
왜 그것이 유용한지 보여주는 제안이 더 있을 수 있습니까?

아마도 우리는 문제를 정리하고 논의된 내용을 요약하여 해결책을 찾아야 할 것입니다.

내가 이해하는 두 가지 제안이 있습니다.

1. 인터페이스와 유형은 정적 속성과 메서드를 정의할 수 있습니다.

interface ISerializable<T> { 
   static fromJson(json: string): T;
}

1. 추상 클래스는 추상 정적 메서드를 정의할 수 있습니다.

abstract class MyClass<T> implements ISerializable<T> {
   abstract static fromJson(json: string): T;
}

class MyOtherClass extends MyClass<any> {
  static fromJson(json: string) {
  // unique implementation
  }
}

제안 1에 관해서는 기술적으로 해결 방법이 있습니다! 대단한 것은 아니지만 최소한 그 정도는 됩니다. 그러나 그것은 해결 방법입니다.

인터페이스를 둘로 나누고 다음과 같이 클래스를 다시 작성할 수 있습니다.

interface StaticInterface {
  new(...args) => MyClass;
  fromJson(json): MyClass;
}

interface InstanceInterface {
  toJson(): string;
}

const MyClass: StaticInterface = class implements InstanceInterface {
   ...
}

내 생각에 이것은 많은 추가 작업과 약간 덜 가독성이 있으며 단순히 이상하고 우리가 사용하는 구문에서 벗어나는 재미있는 방식으로 클래스를 다시 작성하는 단점이 있습니다.

그러나 제안 2는 어떻습니까? 그것에 대해 할 수 있는 일은 아무것도 없잖아요? 그것도 다룰 가치가 있다고 생각합니다!

이러한 유형 중 하나의 실제 용도는 무엇입니까? 이 유형 중 하나는 어떻게 사용됩니까?

interface JsonSerializable {
    toJSON(): string;
    static fromJSON(serializedValue: string): JsonSerializable;
}

값은 { fromJSON(serializedValue: string): JsonSerializable; } 와 같은 객체여야 한다고 이미 말할 수 있습니다. 그래서 이것은 단지 패턴을 적용하기 위해 원하는 것입니까? 나는 유형 검사 관점에서 이점을 보지 못합니다. 참고로 이 경우 작업하기 어려운 패턴이 적용됩니다. 여기서 다루지 않을 여러 가지 이유로 직렬화 프로세스를 별도의 직렬 변환기 클래스 또는 함수로 이동하는 것이 좋습니다.

게다가 왜 이런 일이 일어나고 있습니까?

class FirstChildClass extends AbstractParentClass {
    public static getSomeClassDependentValue(): string {
        return 'Some class-dependent value of class FirstChildClass';
    }
}

대신 템플릿 방법이나 전략 패턴을 사용하는 것은 어떻습니까? 그렇게 하면 더 유연하게 작동할 것입니다. 맞죠?

현재로서는 작업하기 힘든 클래스 디자인을 설명하기 위해 불필요한 복잡성을 추가하는 것처럼 보이기 때문에 이 기능에 반대합니다. 내가 놓치고 있는 이점이 있을 수 있습니까?

정적 React 메서드에 대한 유효한 사용 사례가 하나 있습니다.

@aleksey-bykov 아, 알겠습니다. 이러한 경우 constructor 속성에 유형을 추가하면 드문 시나리오에서 유형 검사가 발생하는 것이 더 나을 수 있습니다. 예를 들어:

interface Component {
    constructor: ComponentConstructor;
}

interface ComponentConstructor {
    displayName?: string;
}

class MyComponent implements Component {
    static displayName = 5; // error
}

그것이 나에게 훨씬 더 가치가 있는 것 같다. 그것은 언어에 추가적인 복잡성을 추가하지 않으며 클래스가 인터페이스를 올바르게 구현하는지 확인할 때 유형 검사기에 더 많은 작업을 추가할 뿐입니다.

그건 그렇고, 유효한 사용 사례는 인스턴스에서 생성자로 이동하고 마지막으로 유형 검사가 있는 정적 메서드 또는 속성으로 이동할 때라고 생각했지만 유형에 constructor 속성을 입력하면 이미 가능합니다. #3841의 클래스 인스턴스에 대해 해결됩니다.

나는 비슷한 생각을 가지고 있었다 : https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -437071092

업스레드에 설명된 직렬화/역직렬화 패턴이 "유효"하지 않습니까?

@dsherret 은 "유형 검사 관점에서 이점을 보지 못합니다". 먼저 정적 분석을 수행하는 요점은 가능한 한 빨리 오류를 포착하는 것입니다. 호출 서명을 변경해야 하는 경우 호출하는 모든 사람, 또는 결정적으로 서명을 사용하는 메서드 구현을 담당하는 모든 사람이 새 서명으로 업데이트하도록 입력합니다.

정적 foo(x: number, y: boolean, z: string) 메서드가 있는 형제 클래스 세트를 제공하는 라이브러리가 있고 사용자가 이러한 클래스 중 여러 개를 사용하고 인스턴스를 생성하기 위해 메서드를 호출하는 팩토리 클래스를 작성할 것으로 예상한다고 가정합니다. (아마도 deserialize 또는 clone 또는 unpack 또는 loadFromServer , 중요하지 않습니다.) 사용자는 또한 동일한(추상적일 수 있는) 부모의 하위 클래스를 만듭니다. 도서관에서 수업.

이제 마지막 매개변수가 옵션 객체가 되도록 해당 계약을 변경해야 합니다. 세 번째 인수에 대한 문자열 값을 전달하는 것은 컴파일 타임에 플래그를 지정해야 하는 복구할 수 없는 오류입니다. foo 를 호출할 때 대신 객체를 전달하도록 모든 팩토리 클래스를 업데이트해야 하며 foo 를 구현하는 하위 클래스는 호출 서명을 변경해야 합니다.

새 라이브러리 버전으로 업데이트하는 사용자가 컴파일 타임에 주요 변경 사항을 포착할 수 있도록 보장하고 싶습니다. 라이브러리는 위의 정적 인터페이스 해결 방법 중 하나(예 type MyClass = (new (data: number[]) => MyInterface) & MyStaticInterface; )를 내보내고 소비자가 올바른 위치에 적용하기를 바랍니다. 구현 중 하나를 장식하는 것을 잊었거나 팩토리 클래스에서 foo 의 호출 서명을 설명하기 위해 라이브러리 내보낸 유형을 사용하지 않은 경우 컴파일러는 변경된 사항을 알 수 없으며 런타임 오류가 발생합니다. . 부모 클래스에서 abstract static 메서드를 합리적으로 구현하는 것과 대조적으로 -- 특별한 주석이 필요하지 않고 소비 코드에 대한 부담이 없으며 즉시 작동합니다.

@thw0rted 대부분의 라이브러리는 이러한 클래스의 등록을 요구하지 않으며 그 시점에서 유형 검사가 발생할 수 있습니까? 예를 들어:

// in the library code...
class SomeLibraryContext {
    register(classCtor: Function & { deserialize(serializedString: string): Component; }) {
        // etc...
    }
}

// then in the user's code
class MyComponent extends Comonent {
    static deserialize(serializedString: string) {
        return JSON.parse(serializedString) as Component;
    }
}

const context = new SomeLibraryContext();
// type checking occurs here today. This ensures `MyComponent` has a static deserialize method
context.register(MyComponent);

아니면 이러한 클래스의 인스턴스가 라이브러리와 함께 사용되고 라이브러리가 정적 메서드를 가져오기 위해 인스턴스에서 생성자로 이동합니까? 그렇다면 정적 메서드가 필요하지 않도록 라이브러리 디자인을 변경할 수 있습니다.

참고로 인터페이스의 구현자로서 생성자가 없기 때문에 정적 메서드에 종속성을 주입하기가 매우 어렵기 때문에 정적 메서드를 작성해야 하는 경우 매우 짜증이 날 것입니다(ctor 종속성은 가능하지 않음). 또한 상황에 따라 역직렬화 구현을 다른 것으로 바꾸는 것도 어렵게 만듭니다. 예를 들어 다른 직렬화 메커니즘을 사용하여 다른 소스에서 역직렬화하고 있다고 가정해 보겠습니다. 이제 정적 역직렬화 메서드가 있습니다. 이 메서드는 설계상 클래스 구현에 대해 한 가지 방법으로만 구현할 수 있습니다. 이 문제를 해결하려면 정적 역직렬화 메서드에 사용할 항목을 알려주는 다른 전역 정적 속성이나 메서드가 클래스에 있어야 합니다. 사용할 항목을 쉽게 바꿀 수 있고 (역)직렬화되는 클래스에 (역)직렬화를 연결하지 않는 별도의 Serializer 인터페이스를 선호합니다.

무슨 말인지 알겠습니다. 팩토리 패턴을 사용하려면 결국 구현 클래스를 팩토리에 전달해야 하며 이때 정적 검사가 발생합니다. 나는 여전히 공장 호환 클래스를 제공하고 싶지만 지금은 실제로 사용하지 않는 경우가 있을 수 있다고 생각합니다. 이 경우 abstract static 제약 조건이 문제를 더 일찍 포착하고 의미를 더 명확하게 만듭니다.

나는 당신의 "sidenote" 관심사에 어긋나지 않는다고 생각하는 또 다른 예가 있습니다. 나는 사용자에게 특정 기능에 사용할 "제공자"를 선택하도록 하는 프론트엔드 프로젝트에 여러 형제 클래스가 있습니다. 물론 name => Provider 어딘가에 사전을 만들고 키를 사용하여 선택 목록에 표시할 내용을 결정할 수 있지만 지금 구현한 방법은 정적 name 필드를 요구하는 것입니다. 각 공급자 구현에서.

어느 시점에서 shortName 및 longName (사용 가능한 화면 공간의 양이 서로 다른 컨텍스트에서 표시하기 위해)를 모두 요구하도록 변경했습니다. $#$ providerList: Type<Provider> & { shortName: string } & { longName: string } 를 가지도록 선택 목록 구성 요소를 변경하는 대신 abstract static name: string; 를 abstract static shortName: string; 등으로 변경하는 것이 훨씬 더 간단했을 것입니다. 의도를 올바른 위치 (즉, 소비 구성 요소가 아닌 추상 부모)에 전달하고 읽기 쉽고 변경하기 쉽습니다. 해결 방법이 있다고 말할 수 있다고 생각하지만 여전히 제안된 변경 사항보다 객관적으로 더 나쁘다고 생각합니다.

최근에 인터페이스에서 정적 메서드를 사용해야 할 때 이 문제를 발견했습니다. 이 많은 댓글을 읽을 시간이 없기 때문에 이 문제가 이전에 이미 해결된 경우 사과드립니다.

내 현재 문제: 내 TypeScript 프로젝트에서 사용하려는 개인 .js 라이브러리가 있습니다. 그래서 계속해서 해당 라이브러리에 대한 .d.ts 파일을 작성하기 시작했지만 라이브러리가 정적 메서드를 사용하기 때문에 실제로 완료할 수 없었습니다. 이 경우 제안된 접근 방식은 무엇입니까?

답변 감사합니다.

@greeny https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -449610196

@greeny 는 작동하는 솔루션입니다. https://github.com/Microsoft/TypeScript/issues/14600#issuecomment -437071092

특히 이 부분:

type MyClass = (new (text: string) => MyInterface) & { myStaticMethod(): string; }

또 다른 사용 사례: 생성된 코드/부분 클래스 shim

• 나는 swagger 사양을 생성하는 @rsuter/nswag 라이브러리를 사용하고 있습니다.
• 생성된 파일에 병합되는 '확장' 파일을 작성할 수 있습니다.
• 확장 파일은 실행되지 않지만 자체적으로 컴파일해야 합니다!
• 때때로 그 파일 내에서 아직 존재하지 않는 것을 참조해야 합니다(생성되기 때문에)
• 따라서 다음과 같이 shim/인터페이스를 선언하고 싶습니다.
• 참고: 최종 병합에서 특정 import 문이 무시되도록 지정할 수 있으므로 최종 생성 코드에서 'shim' 포함이 무시됩니다.

interface SwaggerException
{
    static isSwaggerException(obj: any): obj is SwaggerException;
}

그러나 나는 이것을 할 수 없으며 실제로 클래스를 작성해야 합니다. 이것은 괜찮지만 여전히 잘못된 느낌입니다. 나는 단지 - 다른 많은 사람들이 말했듯이 - '이것이 계약이다'라고 말하고 싶습니다.

코드 생성에 대한 다른 언급을 볼 수 없기 때문에 여기에 추가하고 싶었습니다. 하지만 많은 '이것이 필요한 이유' 주석은 ​​짜증을 유발합니다. 인터페이스에서 이 '정적' 기능을 '필요로 하는' 상당한 비율의 사람들이 외부 라이브러리 항목을 참조할 수 있도록 해당 기능을 수행할 것으로 예상합니다.

또한 더 깨끗한 d.ts 파일을 보고 싶습니다. 이 기능과 해당 파일과 겹치는 부분이 있어야 합니다. JQueryStatic 같은 것은 그냥 해킹처럼 보이기 때문에 이해하기 어렵습니다. 또한 현실은 d.ts 파일이 종종 오래 되고 유지 관리되지 않으며 shim을 직접 선언해야 합니다.

(jQuery를 언급해서 죄송합니다)

직렬화의 경우 나는 그런 일을했습니다.

export abstract class World {

    protected constructor(json?: object) {
        if (json) {
            this.parseJson(json);
        }
    }

    /**
     * Apply data from a plain object to world. For example from a network request.
     * <strong i="6">@param</strong> json Parsed json object
     */
    abstract parseJson(json: object): void;

    /**
     * Parse instance to plane object. For example to send it through network.
     */
    abstract toJson(): object;
}

그러나 다음과 같은 것을 사용하는 것이 훨씬 더 쉬울 것입니다.

export abstract class World {

    /**
     * Create a world from plain object. For example from a network request.
     * <strong i="10">@param</strong> json Parsed json object
     */
    abstract static fromJson(json: object): World;

    /**
     * Parse instance to plane object. For example to send it through network.
     */
    abstract toJson(): object;
}

나는 이 쓰레드를 많이 적었지만 나는 여전히 왜 이 패턴에 대해 아니오라고 말하는 것이 좋고 올바른지 이해하지 못합니다. 당신이 그 의견을 공유한다면, 당신은 또한 자바와 다른 인기 있는 언어들이 그것을 잘못 만든다고 말합니다. 아니면 내가 틀렸습니까?

이 문제는 2년 동안 공개되었으며 79개의 댓글이 있습니다. Awaiting More Feedback 로 레이블이 지정됩니다. 결정을 내리기 위해 어떤 피드백이 더 필요한지 말씀해 주시겠습니까?

인터페이스나 추상 클래스(선언만 해당)에서 정적 메서드를 설명할 수 없다는 것은 정말 짜증나는 일입니다. 이 기능이 아직 구현되지 않았기 때문에 해결 방법을 작성하는 것은 너무 추악합니다 =(

예를 들어 next.js는 페이지를 구성하기 전에 페이지 속성을 가져오기 위해 정적 getInitialProps 함수를 사용합니다. throw되는 경우 페이지가 생성되지 않고 오류 페이지가 생성됩니다.

https://github.com/zeit/next.js/blob/master/packages/next/README.md#fetching -data-and-component-lifecycle

그러나 불행하게도, 이 메소드를 구현하는 단서 ts는 유형 검사가 불가능하기 때문에 런타임에 오류가 발생하더라도 모든 유형 서명을 제공할 수 있습니다.

자바스크립트 자체가 정적인 걸 잘 못해서 이 문제가 여기 오래 존재하는 것 같아요 🤔

정적 상속은 애초에 존재해서는 안 됩니다. 🤔🤔

누가 정적 메서드를 호출하거나 정적 필드를 읽고 싶습니까? 🤔🤔🤔

• 자식 클래스: 정적이 아니어야 합니다.
• 부모 클래스: 생성자 인수 사용
• 기타: ISomeClassConstructor 인터페이스 사용

다른 사용 사례가 있습니까?🤔🤔🤔🤔

이것에 대한 업데이트가 있습니까?

도움이 된다면 클래스의 정적 인터페이스를 입력해야 하는 경우에 수행한 작업은 데코레이터를 사용하여 클래스의 정적 멤버를 적용하는 것입니다.

데코레이터는 다음과 같이 정의됩니다.

export const statics = <T extends new (...args: Array<unknown>) => void>(): ((c: T) => void) => (_ctor: T): void => {};

다음과 같이 정의된 정적 생성자 멤버 인터페이스가 있는 경우

interface MyStaticType {
  new (urn: string): MyAbstractClass;
  isMember: boolean;
}

T의 멤버를 다음과 같이 정적으로 선언해야 하는 클래스에서 호출됩니다.

@statics<MyStaticType>()
class MyClassWithStaticMembers extends MyAbstractClass {
  static isMember: boolean = true;
  // ...
}

가장 빈번한 예는 다음과 같습니다.

interface JsonSerializable {
    toJSON(): string;
    static fromJSON(serializedValue: string): JsonSerializable;
}

그러나 여기 #13462에서 말했듯이 :

인터페이스는 개체가 제공하는 기능을 정의해야 합니다. 이 기능은 재정의 가능하고 상호 교환 가능해야 합니다(이것이 인터페이스 메소드가 가상인 이유입니다). 정적은 동적 동작/가상 방법과 유사한 개념입니다.

TypeScript에서 인터페이스는 개체 인스턴스 자체와 사용 방법을 설명한다는 점에 동의합니다. 문제는 개체 인스턴스가 클래스 정의가 아니며 static 기호가 클래스 정의에만 존재할 수 있다는 것입니다.

그래서 나는 모든 결점과 함께 다음을 제안할 수 있습니다.

인터페이스는 개체 또는 클래스 를 설명할 수 있습니다. 클래스 인터페이스가 class_interface 키워드로 표시된다고 가정해 보겠습니다.

class_interface ISerDes {
    serialize(): string;
    static deserialize(str: string): ISerDes
}

클래스(및 클래스 인터페이스)는 statically implements 키워드를 사용하여 개체 인터페이스를 사용하여 정적 기호를 선언할 수 있습니다( 클래스 인터페이스는 statically 구현될 수 없음).

클래스(및 클래스 인터페이스)는 여전히 개체 인터페이스 또는 클래스 인터페이스와 함께 implements 키워드를 사용합니다.

클래스 인터페이스는 정적으로 구현된 객체 인터페이스와 인스턴스 구현 인터페이스를 혼합할 수 있습니다. 따라서 다음을 얻을 수 있습니다.

interface ISerializable{
    serialize(): string;
}
interface IDeserializable{
    deserialize(str: string): ISerializable
}

class_interface ISerDes implements ISerializable statically implements IDeserializable {}

이런 식으로 인터페이스는 의미를 유지할 수 있고 class_interface 는 클래스 정의 전용의 새로운 종류의 추상화 기호가 됩니다.

중요하지 않은 작은 사용 사례 하나 더:
Angular for AOT 컴파일에서는 데코레이터에서 함수를 호출할 수 없습니다(예: @NgModule 모듈 데코레이터).
각도 문제

서비스 작업자 모듈의 경우 다음과 같은 것이 필요합니다.
ServiceWorkerModule.register('ngsw-worker.js', {enabled: environment.production})
기본 값과 구현할 추상 속성으로 추상 클래스를 확장하는 하위 클래스를 사용하는 환경입니다. 유사한 구현 예
따라서 클래스 생성이 함수이고 다음과 같은 오류가 발생하기 때문에 AOT가 작동하지 않습니다. Function calls are not supported in decorators but ..

작동하게 하고 자동 완성/컴파일러 지원을 유지하려면 정적 수준에서 동일한 속성을 정의할 수 있습니다. 그러나 '구현' 속성을 위해서는 추상 클래스의 정적 멤버 또는 추상 정적 멤버와의 인터페이스가 필요합니다. 둘 다 아직 불가능합니다.

인터페이스를 사용하면 다음과 같이 작동할 수 있습니다.

// default.env.ts
interface ImplementThis {
  static propToImplement: boolean;
}

class DefaultEnv {
  public static production: boolean = false;
}

// my.env.ts
class Env extends DefaultEnv implements ImplementThis {
  public static propToImplement: true;
}

export const environment = Env;

추상 정적을 사용하면 다음과 같이 작동할 수 있습니다.

// default.env.ts
export abstract class AbstractDefaultEnv {
  public static production: boolean = false;
  public abstract static propToImplement: boolean;
}
// my.env.ts
class Env extends AbstractDefaultEnv {
  public static propToImplement: true;
}

export const environment = Env;

해결 방법 이 있지만 모두 약합니다./

@DanielRosenwasser @RyanCavanaugh 는 언급에 대해 사과하지만 커뮤니티의 많은 지원을 받고 있고 구현하기가 상당히 쉬울 것이라고 생각하는 이 기능 제안이 문제 범주에 깊숙이 묻힌 것 같습니다. 이 기능에 대한 의견이 있으신가요? PR을 환영합니까?

이 문제는 #1263의 복제본이 아닙니까? 😛

26398(구현 유형의 생성자 속성을 기반으로 하는 유형 검사 정적 멤버)가 더 나은 솔루션처럼 보입니다... 이와 같은 것이 구현된다면 그것이 바로 그것일 것입니다. 추가 구문/파싱이 필요하지 않으며 단일 시나리오에 대한 유형 검사 변경일 뿐입니다. 또한 이것만큼 많은 질문을 제기하지 않습니다.

인터페이스의 정적 메서드는 추상 클래스에 정적 추상 메서드를 사용하는 것만큼 직관적이지 않은 것 같습니다.

인터페이스는 클래스가 아닌 객체를 정의해야 하기 때문에 인터페이스에 정적 메서드를 추가하는 것은 약간 스케치적이라고 생각합니다. 반면에 추상 클래스는 하위 클래스를 정의하는 데 사용되므로 추상 클래스에는 정적 추상 메서드가 있어야 합니다. 이 구현이 진행되는 한, 추상 클래스를 확장할 때(예: class extends MyAbstractClass ), 유형으로 사용할 때(예: let myInstance: MyAbstractClass )가 아니라 유형 검사만 하면 됩니다.

예시:

abstract class MyAbstractClass {
  static abstract bar(): number;
}

class Foo extends MyAbstractClass {
  static bar() {
    return 42;
  }
}

지금은 부득이하게 이것을 사용합니다

abstract class MultiWalletInterface {

  static getInstance() {} // can't write a return type MultiWalletInterface

  static deleteInstance() {}

  /**
   * Returns new random  12 words mnemonic seed phrase
   */
  static generateMnemonic(): string {
    return generateMnemonic();
  }
}

이것은 불편하다!

"개체"에 속성을 추가하는 문제가 발생했습니다. 여기에 샌드박스 예제 가 있습니다.

interface Object {
    getInstanceId: (object: any) => number;
}

Object.getInstanceId = () => 42;
const someObject = {};
Object.getInstanceId(someObject); // correct
someObject.getInstanceId({}); // should raise an error but does not

이제 모든 개체 인스턴스에는 getInstanceId 속성이 있는 것으로 간주되지만 Object 있어야 합니다. 정적 속성이 있으면 문제가 해결되었을 것입니다.

Object가 아닌 ObjectConstructor를 보강하고 싶습니다. 실제로 생성자 자체에 메서드를 연결하려는 경우 인스턴스 메서드를 선언합니다. 선언 병합을 통해 이것이 이미 가능하다고 생각합니다.

````
전역 선언 {
인터페이스 객체 생성자 {
안녕하세요(): 문자열;
}
}

Object.hello();
````

@thw0rted 훌륭합니다! ObjectConstructor를 몰랐습니다 감사합니다

더 큰 요점은 인스턴스 유형이 아닌 생성자 유형을 보강하고 있다는 것입니다. 방금 lib.es5.d.ts 에서 Object 선언을 조회한 결과 ObjectConstructor 유형임을 발견했습니다.

이 문제가 여전히 주변에 있다는 것이 믿기 어렵습니다. 이것은 몇 가지 실제 사용 사례와 함께 합법적으로 유용한 기능입니다.

TypeScript의 요점은 우리 코드베이스에서 유형 안전성을 보장할 수 있다는 것인데, 이 기능이 2년 동안의 피드백 후에도 여전히 "피드백 대기 중"인 이유는 무엇입니까?

나는 이것에서 벗어날 수 있지만 Python의 메타 클래스 와 같은 것이 TypeScript의 패러다임을 위반하지 않고(즉, 인스턴스에 대해 별도의 TypeScript 유형을 유지하고 클래스)?

이 같은:

interface DeserializingClass<T> {
    fromJson(serializedValue: string): T;
}

interface Serializable {
    toJson(): string;
}

class Foo implements Serializable metaclass DeserializingClass<Foo> {
    static fromJson(serializedValue: string): Foo {
        // ...
    }

    toJson(): string {
        // ...
    }
}

// And an example of how this might be used:
function saveObject(Serializable obj): void {
    const serialized: string = obj.toJson();
    writeToDatabase(serialized);
}

function retrieveObject<T metaclass DeserializingClass<T>>(): T {
    const serialized: string = getFromDatabase();
    return T.fromJson(serialized);
}

const foo: Foo = new Foo();
saveObject(foo);

const bar: Foo = retrieveObject<Foo>();

솔직히 이 접근 방식의 가장 까다로운 부분은 metaclass ... staticimplements , classimplements , withstatic 에 대한 의미 있는 TypeScript-y 키워드를 찾는 것 같습니다. implementsstatic ... 확실하지 않습니다.

이것은 @GerkinDev 의 제안 과 약간 비슷하지만 별도의 인터페이스가 없습니다. 여기서 인터페이스의 개념은 하나이며 인스턴스나 클래스의 모양을 설명하는 데 사용할 수 있습니다. 구현하는 클래스 정의의 키워드는 컴파일러에게 각 인터페이스를 검사해야 하는 쪽을 알려줍니다.

원하는 기능에 따라 #34516 및 #33892에서 토론을 시작하겠습니다.