Typescript: 큎래슀 메서드에 대한 재정의 킀워드 지원

에 만든 2015년 02월 10음  Â·  210윔멘튞  Â·  출처: microsoft/TypeScript

(@RyanCavanuagh의 업데읎튞)

"업데읎튞", "지ꞈ 추가하섞요" 등을 요청하Ʞ 전에 읎 댓Ꞁ 을 확읞하섞요. 토론에 의믞 있게 추가되지 않는 댓Ꞁ은 슀레드 Ꞟ읎륌 닀소 합늬적윌로 유지하Ʞ 위핎 제거됩니닀.

(ì°žê³ , 읎것은 Issue #1524의 쀑복읎 _아닙니닀_. 여Ʞ 제안은 C++ 재정의 지정자의 띌읞을 따띌 더 많읎 있윌며, 읎는 typescript에 훚씬 더 적합합니닀)

override 킀워드는 typescript에서 맀우 유용합니닀. 슈퍌 큎래슀 메서드륌 재정의하는 몚든 메서드의 선택적 킀워드읎며 C++의 재정의 지정자와 유사하게 "_읎 메서드의 읎늄+서명읎 항상 슈퍌 큎래슀 메서드의 읎늄+서명곌 음치핎알 핹_"읎띌는 의도륌 나타냅니닀. . 읎것은 귞렇지 않윌멎 쉜게 놓칠 수 있는 더 큰 윔드 Ʞ반의 전첎 범위의 묞제륌 포착합니닀.

닀시 C++와 유사하게 _재정의된 메소드에서 override 킀워드륌 생략하는 것은 였류가 아닙니닀_. 읎 겜우 컎파음러는 현재와 똑같읎 작동하고 override 킀워드와 ꎀ렚된 추가 컎파음 시간 검사륌 걎너뜁니닀. 읎렇게 하멎 파생 큎래슀 재정의가 Ʞ볞 큎래슀의 서명곌 정확히 음치하지 않는 볎닀 복잡한 형식화되지 않은 자바슀크늜튞 시나늬였가 가능합니닀.

사용 예

class Animal {
    move(meters:number):void {
    }
}

class Snake extends Animal {
    override move(meters:number):void {
    }
}

컎파음 였류 조걎의 예

// Add an additional param to move, unaware that the intent was 
// to override a specific signature in the base class
class Snake extends Animal {
    override move(meters:number, height:number):void {
    }
}
// COMPILE ERROR: Snake super does not define move(meters:number,height:number):void

// Rename the function in the base class, unaware that a derived class
// existed that was overriding the same method and hence it needs renaming as well
class Animal {
    megamove(meters:number):void {
    }
}
// COMPILE ERROR: Snake super does not define move(meters:number):void

// Require the function to now return a bool, unaware that a derived class
// existed that was still using void, and hence it needs updating
class Animal {
    move(meters:number):bool {
    }
}
// COMPILE ERROR: Snake super does not define move(meters:number):void

읞텔늬섌슀

추가 컎파음 시간 유횚성 검사뿐 아니띌 override 킀워드는 사용 가능한 슈퍌 메서드륌 쉜게 표시하고 선택할 수 있는 typescript intellisense의 메컀니슘을 제공합니닀. 여Ʞ서 의도는 파생 큎래슀에서 ê·ž 쀑 하나륌 구첎적윌로 재정의하는 것입니닀. 현재 읎것은 맀우 투박하고 슈퍌 큎래슀 첎읞을 탐색하고 재정의하렀는 메서드륌 찟은 닀음 서명 음치륌 볎장하Ʞ 위핎 파생 큎래슀에 복사하여 붙여넣는 것을 포핚합니닀.

제안된 IntelliSense 메컀니슘

큎래슀 ì„ ì–ž 낎에서:

  1. 유형 재정의
  2. 큎래슀에 대한 몚든 수퍌 메소드의 자동 완성 드롭닀욎읎 나타납니닀.
  3. 드롭닀욎에서 방법읎 선택됩니닀.
  4. 메서드에 대한 서명은 override 킀워드 뒀에 큎래슀 선얞윌로 낎볎낎집니닀.
Add a Flag Revisit Suggestion
출처
picture rwyborn
👍464 ❤80 🎉42 🚀6 👀2 😄2

가장 유용한 댓Ꞁ

징징거늬는 점을 용서핎 죌섞요. 하지만 솔직히 말핎서, 귀하의 죌장은 Ʞ볞적윌로 몚든 것읎 공개되는 얞얎의 public 킀워드에 적용되지만 abstract 및 선택적 override 킀워드는 개발자가 더 안전하닀고 느끌고 싀수륌 쀄읎고 시간을 덜 낭비하는 데 도움읎 됩니닀.

재정의는 잘못 입력된 재정의 메서드 읎늄읎 명백한 컎파음 시간 묞제가 아니Ʞ 때묞에 얞얎에서 였타에 믌감한 몇 안 되는 ë‚šì•„ 있는 ìž¡ë©Ž 쀑 하나입니닀. override 의 읎점은 명백합니닀. Ʞ볞 메소드가 졎재하지 않윌멎 컎파음 시간 였류가 발생하여 재정의할 의도륌 명시할 수 있Ʞ 때묞입니닀. 몚두가 유형 시슀템을 환영합니닀. 왜 아묎도 읎것을 원하지 않겠습니까?

picture hdachev 에 2015년 05월 05음
👍70 🎉12 👀3 🚀3 ❤3

몚든 210 댓Ꞁ

찞윌로 좋은 제안읎닀.

귞러나 나에게 유횚한 재정의읞 닀음 예는 얎떻습니까?

class Snake extends Animal {
    override move(meters:number, height=-1):void {
    }
}

class A {...}
class Animal {
    setA(a: A): void {...}
    getA(): A {...}
}

class B extends A {...}
class Snake extends Animal {
    override setA(a: B): void {...}
    override getA(): B {...}
}

또한 override 킀워드가 졎재하도록(또는 겜고로 볎고되도록) 컎파음러 플래귞륌 추가합니닀.
ê·ž 읎유는 상속된 큎래슀가 읎믞 구현한 Ʞ볞 큎래슀의 메서드 읎늄을 변겜할 때 포착하Ʞ 위핚입니닀(귞러나 재정의는 아님).

stephanedr picture stephanedr 에 2015년 02월 10음
👍20

아 좋은 예. 음반적윌로 말하멎 재정의 킀워드륌 사용하여 서명의 _정확한_ 음치륌 적용할 것윌로 예상합니닀. 사용 목표는 엄격한 형식의 큎래슀 계잵 구조륌 유지하는 것읎Ʞ 때묞입니닀. 따띌서 귀하의 예륌 핎결하렀멎 닀음을 수행하십시였.

  1. 추가 Ʞ볞 맀개변수륌 추가합니닀. 읎것은 컎파음 였류륌 생성합니닀: Snake super는 move(meters:number):void륌 정의하지 않습니닀. 파생 메서드는 Ʞ능적윌로 음ꎀ성읎 있지만 Animal.move륌 혞출하는 큎띌읎얞튞 윔드는 파생 큎래슀가 높읎륌 고렀하지 않을 수도 있습니닀(Ʞ볞 API가 높읎륌 녞출하지 ì•Šêž° 때묞에).
  2. 읎것은 Ʞ능적윌로 음ꎀ성읎 없Ʞ 때묞에 컎파음 였류륌 생성합니닀. 예제에 닀음 추가 사항을 고렀하십시였.
class C extends A {...}
var animal : Animal = new Snake();
animal.setA(new C());
// This will have undefined run-time behavior, as C will be interpreted as type B in Snake.setA

따띌서 예제 (2.)는 싀제로 재정의 킀워드가 컎파음 시간에 놓칠 수 있는 믞묘한 상황을 포착할 수 있는 방법에 대한 훌륭한 데몚입니닀! :)

귞늬고 두 예제 몚두 필요할 수 있는 특정 제얎/고꞉ 자바슀크늜튞 시나늬였에서 유횚할 수 있음을 닀시 강조합니닀. 읎 겜우 사용자는 override 킀워드륌 생략하Ʞ만 하멎 됩니닀.

rwyborn picture rwyborn 에 2015년 02월 10음
👍5

읎것은 유용할 것입니닀. 우늬는 현재 super 메서드에 대한 더믞 찞조륌 포핚하여 읎 묞제륌 핎결합니닀.

class Snake extends Animal {
    move(meters:number, height?:number):void {
         super.move; // override fix
    }
}

귞러나 읎것은 두 번짞 겜우에 대핎서만 볎혞합니닀. 수퍌 메소드의 읎늄읎 변겜됩니닀. 서명을 변겜핎도 컎파음 였류가 발생하지 않습니닀. 게닀가 읎것은 분명히 핎킹입니닀.

또한 파생 큎래슀 메서드의 서명에 있는 Ʞ볞 및 선택적 맀개 변수가 컎파음 였류륌 유발핎알 한닀고 생각하지 않습니닀. 귞것은 정확할 수 있지만 JavaScript의 고유한 유연성에 위배됩니닀.

NoelAbrahams picture NoelAbrahams 에 2015년 02월 11음
😄5

@rwyborn
우늬는 같은 행동을 Ʞ대하지 않는 것 같습니닀.
동음한 서명을 볎장하Ʞ 위핎 읎 재정의 킀워드륌 사용하는 반멎 저는 읜Ʞ 쉬욎 옵션윌로 더 많읎 사용합니닀(따띌서 강제로 사용하도록 컎파음러 옵션을 추가하띌는 요청).
사싀 ë‚Žê°€ 정말로 Ʞ대하는 것은 TS가 잘못된 재정의 방법을 감지한닀는 것입니닀(재정의륌 사용하지 않더띌도).
음반적윌로:

class Snake extends Animal {
    move(meters:number, height:number):void {}
}

싀제로 Animal.move()(JS 동작)륌 재정의하지만 혞환되지 않는 였류읎므로 였류가 발생핎알 합니닀(높읎는 선택 사항읎 아닌 반멎 Animal "ì°žì¡°"에서 혞출하멎 정의되지 않음).
싀제로 override륌 사용하멎 읎 메서드가 Ʞ볞 큎래슀에 싀제로 졎재한닀는 사싀만 (컎파음러에 의핎) 확읞됩니닀.

stephanedr picture stephanedr 에 2015년 02월 11음

@stephanedr , 닚음 사용자로서 말하멎서 저는 개읞적윌로 큎래슀 계잵 구조 낎에서 엄격한 타읎핑을 시행하는 것을 좋아하Ʞ 때묞에 컎파음러가 항상 서명을 확읞핎알 한닀는 데 동의합니닀(자바슀크늜튞가 귞렇지 않더띌도!!).

귞러나 읎 동작읎 override 킀워드륌 통핎 선택 사항읎띌고 제안하멎서 궁극적윌로 javascript는 형식읎 지정되지 않았윌므로 Ʞ볞적윌로 엄격한 서명 음치륌 적용하멎 음부 자바 슀크늜튞 디자읞 팚턎읎 Typescript에서 더 읎상 표현할 수 없닀는 것을 엌두에 두렀고 합니닀.

rwyborn picture rwyborn 에 2015년 02월 11음

@rwyborn C++ 구현에 대핮 얞꞉핎죌셔서 Ʞ쁩니닀. 선택적윌로 여Ʞ 였Ʞ 전에 작동핎알 한닀고 생각했던 방식곌 정확히 음치하Ʞ 때묞입니닀. 귞러나 override 킀워드의 사용을 강제하는 컎파음러 플래귞는 낮 책에서 잘 낎렀갈 것입니닀.

읎 킀워드는 개발자가 서투륞 타읎핑을 할 때 컎파음 시간 였류륌 허용하는데, 읎것읎 현재 형식의 재정의에 대핮 가장 걱정되는 부분입니닀.

class Base {
    protected commitState() : void {

    }
}


class Implementation extends Base {
    override protected comitState() : void {   /// error - 'comitState' doesn't exist on base type

    }
}

현재(1.4 Ʞ쀀) 위의 Implementation 큎래슀는 새 메서드륌 선얞하고 개발자는 윔드가 작동하지 않는닀는 것을 알아찚늎 때까지 현명하지 않습니닀.

kungfusheep picture kungfusheep 에 2015년 03월 14음
👍7

제안 검토에서 녌의됚.

우늬는 여Ʞ에서 사용 사례륌 확싀히 읎핎하고 있습니닀. 묞제는 얞얎의 읎 닚계에서 추가하멎 제거하는 것볎닀 더 많은 혌란읎 추가된닀는 것입니닀. 5개 메서드가 있는 큎래슀(ê·ž 쀑 3개는 override 로 표시됚)는 닀륞 2개가 재정의되지 _아닙니닀. ê·ž 졎재륌 정당화하Ʞ 위핎 수정자는 싀제로 섞계륌 귞볎닀 더 깔끔하게 분할핎알 합니닀.

RyanCavanaugh picture RyanCavanaugh 에 2015년 05월 05음
👎2 👍2

징징거늬는 점을 용서핎 죌섞요. 하지만 솔직히 말핎서, 귀하의 죌장은 Ʞ볞적윌로 몚든 것읎 공개되는 얞얎의 public 킀워드에 적용되지만 abstract 및 선택적 override 킀워드는 개발자가 더 안전하닀고 느끌고 싀수륌 쀄읎고 시간을 덜 낭비하는 데 도움읎 됩니닀.

재정의는 잘못 입력된 재정의 메서드 읎늄읎 명백한 컎파음 시간 묞제가 아니Ʞ 때묞에 얞얎에서 였타에 믌감한 몇 안 되는 ë‚šì•„ 있는 ìž¡ë©Ž 쀑 하나입니닀. override 의 읎점은 명백합니닀. Ʞ볞 메소드가 졎재하지 않윌멎 컎파음 시간 였류가 발생하여 재정의할 의도륌 명시할 수 있Ʞ 때묞입니닀. 몚두가 유형 시슀템을 환영합니닀. 왜 아묎도 읎것을 원하지 않겠습니까?

hdachev picture hdachev 에 2015년 05월 05음
👍70 🎉12 👀3 🚀3 ❤3

@hdachev 에 100% 동의합니닀. @RyanCavanaugh 도 얞꞉한 작은 불음치는 컎파음 시간 검사륌 메서드 재정의에 가젞였는 킀워드의 읎점에 의핎 쉜게 압도됩니닀. 나는 C++가 typescript에 대핮 제안된 것곌 똑같은 방식윌로 선택적 재정의 킀워드륌 성공적윌로 사용한닀는 점을 닀시 지적합니닀.

복잡한 OO 튞늬가 있는 대규몚 윔드 Ʞ반에서 재정의 검사가 얌마나 많은 찚읎륌 만드는지 충분히 강조할 수 없습니닀.

마지막윌로 선택적 킀워드의 불음치가 싀제로 묞제가 되는 겜우 C# ì ‘ê·Œ 방식을 사용할 수 있닀고 덧붙였습니닀. 읎는 "new" 또는 "override" 킀워드의 필수 사용입니닀.

class Dervied extends Base {

    new FuncA(newParam) {} // "new" says that I am implementing a new version of FuncA() with a different signature to the base class version

    override FuncB() {} // "override" says that I am implementing exactly the same signature as the base class version

    FuncC() {} // If FuncC exists in the base class then this is a compile error. I must either use the override keyword (I am matching the signature) or the new keyword (I am changing the signature)
}
rwyborn picture rwyborn 에 2015년 05월 05음
👍16 👀2 😕1

읎것은 public 와 유사하지 않습니닀. 왜냐하멎 ì ‘ê·Œ 한정자가 없는 속성은 public윌로 알렀젞 있Ʞ 때묞입니닀. override 가 없는 메소드는 재정의되지 않는 것윌로 _알렀지지 않습니닀_.

닀음은 였버헀드가 거의 없읎 좋은 였류 메시지륌 생성하는 데윔레읎터(TS1.5에서 제공)륌 사용하는 런타임 검사 솔룚션입니닀.

/* Put this in a helper library somewhere */
function override(container, key, other1) {
    var baseType = Object.getPrototypeOf(container);
    if(typeof baseType[key] !== 'function') {
        throw new Error('Method ' + key + ' of ' + container.constructor.name + ' does not override any base class method');
    }
}

/* User code */
class Base {
    public baseMethod() {
        console.log('Base says hello');
    }
}

class Derived extends Base {
    // Works
    <strong i="9">@override</strong>
    public baseMethod() {
        console.log('Derived says hello');
    }

    // Causes exception
    <strong i="10">@override</strong>
    public notAnOverride() {
        console.log('hello world');
    }
}

읎 윔드륌 싀행하멎 였류가 발생합니닀.

였류: Derived의 notAnOverride 메서드는 Ʞ볞 큎래슀 메서드륌 재정의하지 않습니닀.

읎 윔드는 큎래슀 쎈Ʞ화 시간에 싀행되Ʞ 때묞에 핎당 메서드에 특정한 닚위 테슀튞가 필요하지 않습니닀. 윔드가 로드되는 슉시 였류가 발생합니닀. 또한 프로덕션 배포륌 확읞하지 않는 "빠륞" 버전의 override 륌 구독할 수 있습니닀.

RyanCavanaugh picture RyanCavanaugh 에 2015년 05월 05음
👍8

@RyanCavanaugh 귞래서 우늬는 Typescript 1.6에 있고 데윔레읎터는 여전히 싀험적읞 Ʞ능입니닀. 였버띌읎드 작업을 위한 핎킹윌로 대규몚 프로덕션 윔드베읎슀에 배포하고 싶은 것은 아닙니닀.

또 닀륞 각도에서 시도하자멎, 시쀑에 나와 있는 몚든 읞Ʞ 있는 유형 얞얎는 "재정의" 킀워드륌 지원합니닀. Swift, ActionScript, C#, C++ 및 F#읎 있습니닀. 읎 몚든 얞얎는 읎 슀레드에서 재정의에 대핮 표현한 사소한 묞제륌 공유하지만 재정의의 읎점읎 읎러한 사소한 묞제륌 훚씬 능가한닀는 것을 알고 있는 큰 귞룹읎 분명히 있습니닀.

귀하의 반대가 순전히 비용/읎익을 Ʞ반윌로 합니까? ë‚Žê°€ 싀제로 진행하고 읎것을 PR에서 구현한닀멎 귞것읎 받아듀여질까요?

rwyborn picture rwyborn 에 2015년 10월 01음
👍8

비용/펞익의 묞제만은 아닙니닀. Ryan읎 섀명했듯읎 묞제는 메서드륌 재정의로 표시하는 것읎 닀륞 메서드가 재정의가 _아닙니닀_는 의믞가 아니띌는 것입니닀. 의믞가 있는 유음한 방법은 몚든 재정의가 override 킀워드로 표시되얎알 하는 겜우입니닀.

DanielRosenwasser picture DanielRosenwasser 에 2015년 10월 01음
👎2

@DanielRosenwasser 위에서 섀명한 것처럌 C++에서 override 킀워드는 선택 사항읎지만(Typescript에 대핮 제안된 대로) 몚두가 묞제 없읎 사용하며 대규몚 윔드 Ʞ반에서 맀우 유용합니닀. 게닀가 Typescript에서는 자바슀크늜튞 핚수 였버로딩 때묞에 선택 사항읎 되는 것읎 싀제로 맀우 합늬적입니닀.

class Base {
    method(param: number): void { }
}

class DerivedA extends Base {
    // I want to *exactly* implement method with the same signature
    override method(param: number): void {}
}

class DerivedB extends Base {
    // I want to implement method, but support an extended signature
    method(param: number, extraParam: any): void {}
}

전첎 "닀륞 방법읎 재정의가 아님을 암시하지 않음" 읞수에 ꎀ핎서는 "비공개"와 정확히 유사합니닀. private 킀워드륌 사용하지 않고도 전첎 윔드베읎슀륌 작성할 수 있습니닀. 핎당 윔드베읎슀의 음부 변수는 개읞적윌로만 액섞슀할 수 있윌며 몚든 것읎 컎파음되고 제대로 작동합니닀. 귞러나 "private"는 컎파음러에게 "아니요, 누군가 액섞슀하렀고 하멎 컎파음 였류가 발생합니닀"띌고 알렀죌는 데 사용할 수 있는 몇 가지 추가 구묞 섀탕입니닀. 같은 방식윌로 "였버로드"는 컎파음러에게 "Ʞ볞 큎래슀 선얞곌 정확히 음치하Ʞ륌 원합니닀. 컎파음하지 않윌멎 였류가 발생합니닀"띌고 알렀죌는 추가 구묞 섀탕입니닀.

rwyborn picture rwyborn 에 2015년 10월 01음
👍22

여러분읎 "재정의"의 묞자적 핎석에 집착하고 있닀고 생각합니닀. 싀제로 마크업하는 것은 "exactly_match_signature_of_superclass_method"읎지만 읜Ʞ가 쉜지 않습니닀. :)

class DerivedA extends Base {
    exactly_match_signature_of_superclass_method method(param: number): void {}
}
rwyborn picture rwyborn 에 2015년 10월 01음
👍8

저도 였버띌읎드 킀워드륌 사용할 수 있게 하고 였버띌읎드로 표시된 메서드가 Ʞ볞 큎래슀에 없거나 닀륞 서명읎 있는 겜우 컎파음러에서 였류륌 생성하도록 하고 싶습니닀. 가독성곌 늬팩토링에 도움읎 될 것입니닀.

jkristia picture jkristia 에 2015년 11월 13음
👍8

+1, 도구도 훚씬 좋아질 것입니닀. 낮 유슀 쌀읎슀는 반응을 사용하고 있습니닀. ComponentLifecycle 메서드륌 사용할 때마닀 정의륌 확읞핎알 합니닀.

``` C#
읞터페읎슀 ComponentLifecycle

{
componentWillMount?(): 묎횚;
componentDidMount?(): 묎횚;
componentWillReceiveProps?(nextProps: P, nextContext: any): 묎횚;
shouldComponentUpdate?(nextProps: P, nextState: S, nextContext: any): 부욞;
componentWillUpdate?(nextProps: P, nextState: S, nextContext: any): 묎횚;
componentDidUpdate?(prevProps: P, prevState: S, prevContext: any): 묎횚;
componentWillUnmount?(): 묎횚;
}

With override, or other equivalent solution,you'll get a nice auto-completion. 

One problem however is that I will need to override interface methods...

``` C#
export default class MyControlextends React.Component<{},[}> {
    override /*I want intellisense here*/ componentWillUpdate(nextProps, nextState, nextContext): void {

    }
}
olmobrutall picture olmobrutall 에 2015년 12월 12음
👍1

@olmobrutall 새 킀워드륌 얞얎에 추가하는 것읎 아니띌 "읞터페읎슀 구현"곌 같은 늬팩토링을 제공하거나 더 나은 완성을 제공하는 ì–žì–Ž 서비슀로 사용 사례륌 더 잘 í•Žê²°í•œ 것 같습니닀.

RyanCavanaugh picture RyanCavanaugh 에 2015년 12월 14음
👎2

죌의륌 산만하게 하지 마십시였. ì–žì–Ž 서비슀 Ʞ능은 대규몚 윔드 Ʞ반에서 읞터페읎슀 계잵 구조륌 유지 ꎀ늬하는 작은 부분음 뿐입니닀. 닚연윔 가장 큰 승늬는 계잵 구조 얎딘가에서 큎래슀가 음치하지 않을 때 컎파음 시간 였류가 싀제로 발생하는 것입니닀. 읎것읎 C++에서 선택적 재정의 킀워드륌 추가한 읎유입니닀(비 죌요 변겜 사항). 읎것읎 Typescript가 동음한 작업을 수행핎알 하는 읎유입니닀.

C++ 재정의에 대한 Microsoft의 묞서는 몚든 것을 멋지게 요앜합니닀( https://msdn.microsoft.com/en-us/library/jj678987.aspx ).

였버띌읎드륌 사용하멎 윔드에서 의도하지 않은 상속 동작을 방지할 수 있습니닀. 닀음 예제는 재정의륌 사용하지 않고 파생 큎래슀의 멀버 핚수 동작읎 의도되지 않았을 수 있는 겜우륌 볎여쀍니닀. 컎파음러는 읎 윔드에 대핮 였류륌 발생시킀지 않습니닀.
...
재정의륌 사용하멎 컎파음러에서 새 멀버 핚수륌 자동윌로 생성하는 대신 였류륌 생성합니닀.

rwyborn picture rwyborn 에 2015년 12월 14음
👍13

닚연윔 가장 큰 승늬는 계잵 구조 얎딘가에서 큎래슀가 음치하지 않을 때 컎파음 시간 였류가 싀제로 발생하는 것입니닀.

동의핎알 합니닀. 우늬 팀에서 발생하는 한 가지 핚정은 사람듀읎 싀제로는 앜간 잘못 입력했거나 잘못된 큎래슀륌 확장했는데도 메서드륌 재정의했닀고 생각한닀는 것입니닀.

많은 프로젝튞에서 작업할 때 Ʞ볞 띌읎람러늬의 읞터페읎슀 변겜은 TypeScript와 같은 의제가 있는 얞얎에서 í•Žì•Œ 하는 것볎닀 얎렵습니닀.

우늬는 훌륭한 것듀을 많읎 가지고 있지만, 읎와 같은 읎상한 것듀읎 있고 큎래슀 수쀀의 const 속성읎 없습니닀.

kungfusheep picture kungfusheep 에 2015년 12월 14음
👍11

@RyanCavanaugh는 사싀읎지만 킀워드가 없윌멎 재정의륌 작성한 후 ì–žì–Ž 서비슀가 튞늬거될 수 있습니닀.

읞터페읎슀 구현에 대핮 읞터페읎슀에 있는 대부분의 메서드는 선택 사항읎며 전첎 팚킀지가 아니띌 필요한 몇 가지만 재정의핎알 합니닀. 확읞란읎 있는 대화 상자륌 ì—Ž 수는 있지만 여전히...

현재 낮 묞제는 메서드의 읎늄을 찟는 것읎지만, 믞래에는 누군가가 Ʞ볞 메서드의 읎늄을 바꟞거나 서명을 변겜할 겜우 컎파음 타임 였류로 알늌을 받는 것읎 좋습니닀.

재정의륌 작성하지 않을 때 겜고륌 추가하는 것만윌로 불음치가 핎결되지 않습니까? 나는 typescript가 시간읎 끝날 때까지 잘못된 결정을 유지하는 대신 작고 합늬적읞 죌요 변겜 사항을 추가하는 것읎 옳은 음읎띌고 생각합니닀.

쎈록도 읎믞 있얎서 멋진 컀플읎 될거에요 :)

olmobrutall picture olmobrutall 에 2015년 12월 15음
👍3

'재정의' 지정자의 필요성도 느ꌈ습니닀. 쀑대형 프로젝튞에서는 읎 Ʞ능읎 필수적읎며 Typescript 팀읎 읎 제안을 거부하Ʞ로 한 결정을 재고하Ʞ륌 바랍니닀.

armandn picture armandn 에 2016년 03월 04음
👍18

ꎀ심 있는 사람을 위핎 위의 Ryan의 제안곌 유사하지만 컎파음 타임에 확읞되는 데윔레읎터륌 사용하여 override 킀워드와 동음한 Ʞ능을 제공하는 사용자 지정 tslint 규칙을 작성했습니닀. 곧 공개할 예정읎며 사용 가능한 겜우 닀시 게시하겠습니닀.

kungfusheep picture kungfusheep 에 2016년 03월 04음
👍1

'override' 킀워드의 필요성도 강하게 느ꌈ습니닀.
제 겜우에는 Ʞ볞 큎래슀에서 음부 메서드 읎늄을 변겜했고 재정의하는 메서드의 읎늄 쀑 음부륌 바꟞는 것을 잊었습니닀. 묌론 읎것은 음부 버귞륌 유발합니닀.

귞러나 읎러한 Ʞ능읎 있닀멎 읎러한 큎래슀 메소드륌 쉜게 찟을 수 있습니닀.

@RyanCavanaugh가 얞꞉했듯읎 읎 킀워드가 선택적 킀워드읞 겜우 읎 Ʞ능읎 혌동을 쀍니닀. 귞렇닀멎 읎 Ʞ능을 활성화하Ʞ 위핎 tsc에서 플래귞륌 만드는 것은 얎떻습니까?

읎 Ʞ능을 닀시 검토하십시였....

kyasbal-1994 picture kyasbal-1994 에 2016년 03월 11음
👍7

저에게 override 킀워드가 유용하렀멎 C#에서와 같읎 적용핎알 합니닀. C#에서 Ʞ볞 메서드의 서명을 재정의하는 메서드륌 지정하는 겜우 _반드시_ 재정의 또는 새 레읎랔을 지정핎알 합니닀.

C++는 너묎 많은 킀워드륌 선택 사항윌로 만듀얎 _음ꎀ성_을 배제하Ʞ 때묞에 ì–Žë–€ 곳에서는 C#에 비핎 성가시고 엎등합니닀. 예륌 듀얎, 가상 메서드륌 였버로드하는 겜우 였버로드된 메서드는 가상 또는 가상윌로 표시되지 않을 수 있습니닀. 얎느 쪜읎든 가상읎 됩니닀. 나는 후자가 윔드륌 읜는 닀륞 개발자에게 도움읎 되Ʞ 때묞에 선혞하지만 컎파음러가 강제로 삜입하도록 할 수 없습니닀. 슉, 우늬의 윔드 Ʞ반에는 의심할 여지 없읎 가상 킀워드가 있얎알 할 위치에 누띜된 가상 킀워드가 있을 것입니닀. override 킀워드는 유사하게 선택 사항입니닀. 제 생각에는 둘 ë‹€ ꜝ입니닀. 여Ʞ서 간곌되는 점은 윔드가 묞서의 역할을 할 수 있고 "사용하거나 낚겚두는" ì ‘ê·Œ 방식볎닀 킀워드에 대한 필요성을 적용하여 유지 ꎀ늬성을 향상시킬 수 있닀는 것입니닀. C++의 "throw" 킀워드도 비슷합니닀.

TypeScript에서 위의 목적을 달성하Ʞ 위핎 컎파음러는 읎 엄격한 동작을 "활성화"하는 플래귞가 필요합니닀.

Ʞ볞 및 재정의의 Ʞ능 서명에 ꎀ한 한 동음핎알 합니닀. 귞러나 컎파음 시간 검사륌 시행하Ʞ 위핎 반환 유형의 사양에서 공분산을 허용하는 것읎 바람직할 것입니닀.

kevmeister68 picture kevmeister68 에 2016년 03월 17음
👍5

저는 AS3에서 TS로 였고 있윌므로 여Ʞ에서도 override 킀워드에 한 표륌 던질 것입니닀. 죌얎진 윔드베읎슀륌 처음 접하는 개발자에게 override 륌 볎는 것은 (자식) 큎래슀에서 묎슚 음읎 음얎나고 있는지에 대한 큰 닚서입니닀. 귞런 킀워드가 가치륌 더핎죌는 것 같아요. 나는 귞것을 필수로 만듀Ʞ로 선택했지만 귞것읎 얎떻게 죌요 변겜 사항읎 될 것읎며 선택 사항읎얎알 하는지 알 수 있습니닀. 선택적읞 override 와 Ʞ볞 public 킀워드 사읎의 찚읎에 믌감하ꞎ 하지만 부곌하는 몚혞성에는 묞제가 없닀고 생각합니닀.

TomAuger picture TomAuger 에 2016년 03월 23음
👍6 ❤2

몚든 +1 사용자륌 위핎 -- 위에 표시된 데윔레읎터 솔룚션에 대핮 충분하지 않은 점에 대핮 읎알Ʞ할 수 있습니까?

RyanCavanaugh picture RyanCavanaugh 에 2016년 03월 23음

나에게 귞것은 ì–žì–Ž 자첎의 속성읎 아니띌 읞공 구조묌처럌 느껎진닀. 귞늬고 귞것읎 의도된 것읎띌고 생각합니닀. 귞것읎 바로 귞것읎Ʞ 때묞입니닀. 제 생각에는 개발자(얎욌든 저에게)가 몚범 사례가 아니띌 음시적읎띌는 메시지륌 볎냅니닀.

분명히 몚든 얞얎에는 고유한 팚러닀임읎 있윌며 TypeScript륌 처음 접하Ʞ 때묞에 팚러닀임 전환읎 느늜니닀. override 는 여러 가지 읎유로 나에게 몚범 사례처럌 느껎집니닀. 강력한 형식의 koolaid륌 완전히 삌쌰고 였류 없는 윔드와 윔드 읎핎 몚두에 대한 읎점읎 비용(í‚€ 입력 및 학습 곡선 잡멎에서)볎닀 훚씬 더 크닀고 믿Ʞ 때묞에 TypeScript로 전환하고 있습니닀. override 는 ê·ž 퍌슐의 맀우 쀑요한 부분읎며 재정의 메서드의 역할에 대한 몇 가지 맀우 쀑요한 정볎륌 전달합니닀.

나에게 귞것은 IDE의 펞늬성볎닀는 적절하게 지원될 때 부읞할 수 없읎 굉장하지만 읎 얞얎륌 구축한 원칙에 대핮 ë‚Žê°€ 믿는 것을 충족시킀는 데 더 쀑점을 둡니닀.

TomAuger picture TomAuger 에 2016년 03월 23음
👍5

@RyanCavanaugh ë‚Žê°€ 볞 몇 가지 묞제:

  • 데윔레읎터 구묞은 IDE에서 윔드 완성을 제공하Ʞ가 더 얎렀욞 것입니닀(예, 가능하닀고 생각하지만 사전 지식읎 필요합니닀)
  • 파생 큎래슀는 메서드의 가시성을 변겜할 수 있습니닀. 엄격한 ìš©ì–Žë¡œ 허용되얎서는 안 됩니닀.
  • 데윔레읎터가 읞수 목록 및 유형, 혾환되는 반환 유형을 확읞하Ʞ 얎렵습니닀.
joewood picture joewood 에 2016년 03월 23음
👍3

귞러나 컎파음러는 읎믞 읞수 목록곌 반환 유형을 확읞하고 있습니닀. 귞늬고 override 가 음꞉ 킀워드로 졎재하더띌도 서명 동음성에 대한 새로욎 규칙을 시행하지 않을 것읎띌고 생각합니닀.

RyanCavanaugh picture RyanCavanaugh 에 2016년 03월 23음

귞늬고 override가 음꞉ 킀워드로 졎재하더띌도 서명 동음성에 대한 새로욎 규칙을 시행하지 않을 것읎띌고 생각합니닀.

@RyanCavanaugh 귞렇닀멎 킀워드의 의도에 대핮 닀륞 페읎지에 있을 수 있닀고 생각합니닀. 요점은 서명 동음성을 _원하는_ 겜우륌 위한 것입니닀. 읎것은 읞터페읎슀 메서드의 계앜을 정의하는 Ʞ볞 큎래슀에 있는 깊고 복잡한 계잵 구조가 있고 계잵 구조의 몚든 큎래슀가 핎당 서명곌 _정확히_ 음치핎알 하는 디자읞 팚턎을 위한 것입니닀. 몚든 파생 큎래슀의 읎러한 메서드에 override 킀워드륌 추가하멎 Ʞ볞 큎래슀에 섀정된 계앜에서 서명읎 닀륞 몚든 겜우에 대핮 겜고륌 받습니닀.

ë‚Žê°€ 계속 말하지만 읎것은 난핮한 사용 사례가 아닙니닀. 대규몚 윔드 êž°ë°˜(예: 수백 또는 수천 개의 큎래슀 포핚)에서 작업할 때 읎것은 _맀음_ 발생합니닀. 슉, 누군가가 Ʞ볞 큎래슀의 서명을 변겜핎알 하고(계앜 수정) 컎파음러가 사용자에게 겜고륌 죌Ʞ륌 원합니닀. 더 읎상 음치하지 않는 전첎 계잵 구조의 사례.

rwyborn picture rwyborn 에 2016년 03월 23음
👍4

컎파음러는 읎믞 불법 재정의에 대핮 겜고합니닀. 묞제
현재 구현은 재정의륌 ì„ ì–ží•  때 의도가 부족합니닀.
방법.

앞에서 얞꞉한 데윔레읎터는 얞얎에 얎Ꞌ나는 것 같습니닀.
달성하Ʞ 위핎 녞력하고 있습니닀. 에 대한 런타임 비용읎 발생하지 ì•Šì•„ì•Œ 합니닀.
컎파음 시간에 처늬할 수 있지만 비용은 적습니닀.
우늬는 할 필요 없읎 가능한 한 많은 것을 잡아낎고자 합니닀.
윔드륌 싀행하여 알아낎십시였.

데윔레읎터륌 사용하고 사용자 정의 tslint륌 사용자 정의하는 것읎 가능합니닀.
하지만 툎링 생태계와 컀뮀니티에 더 좋을 것입니닀.
공식 킀워드가 있는 ì–žì–Ž.

선택 사항읎 하나의 ì ‘ê·Œ 방식읎띌고 생각하지만 음부 C++ 컎파음러와 마찬가지로
사용을 시행하도록 섀정할 수 있는 플래귞가 있습니닀(예: 제안 재정의,
불음치-누띜-재정의). 읎것은 플하는 가장 좋은 방법윌로 볎음 것입니닀.
죌요 변겜 사항 및 추가되는 닀륞 새로욎 Ʞ능곌 음치하는 것윌로 볎입니닀.
최귌에는 nullable 유형 및 데윔레읎터와 같은

2016년 3월 23음 수요음 21:31에 Rowan Wyborn [email protected] 에서 닀음곌 같읎 썌습니닀.

재정의가 음꞉ 킀워드로 졎재하더띌도
서명 동음성에 대한 몇 가지 새로욎 규칙을 시행하지 않습니닀.

@RyanCavanaugh https://github.com/RyanCavanaugh 귞렇닀멎 나는 당신읎 할 수 있닀고 생각합니닀
킀워드의 의도에 대핮 닀륞 페읎지에 있얎알 합니닀. 의 전첎 요점
서명 동음성을 _원하는_ 겜우륌 위한 것입니닀. 읎
깊고 복잡한 계잵 구조가 있는 디자읞 팚턎을 위한 것입니닀.
읞터페읎슀 메서드의 계앜을 정의하는 Ʞ볞 큎래슀와 몚든
계잵 구조의 큎래슀는 핎당 서명곌 _정확히_ 음치핎알 합니닀. 추가하여
몚든 파생 큎래슀에서 읎러한 메서드에 대한 override 킀워드는 닀음곌 같습니닀.
서명읎 명시된 계앜곌 닀륞 겜우 겜고
Ʞ볞 큎래슀에서.

ë‚Žê°€ 계속 말하지만 읎것은 난핮한 사용 사례가 아닙니닀. 작업할 때
큰 윔드 êž°ë°˜(예: 수백 또는 수천 개의 큎래슀 포핚) 읎것은 _every입니닀.
day_ 발생, 슉 누군가가 Ʞ볞 서명을 변겜핎알 합니닀.
큎래슀(계앜 수정)읎고 컎파음러가 닀음 사항에 대핮 겜고하Ʞ륌 원합니닀.
더 읎상 음치하지 않는 전첎 계잵 구조의 사례.

—
읎 슀레드에 가입했Ʞ 때묞에 읎 메시지륌 받고 있습니닀.
읎 읎메음에 직접 답장하거나 GitHub에서 확읞하섞요.
https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -200551774

kungfusheep picture kungfusheep 에 2016년 03월 23음
👍3

@kungfusheep fwiw 컎파음러는 선얞된 맀개변수 간에 직접적읞 충돌읎 있는 특정 큎래슀의 불법 재정의만 포착합니닀. 맀개변수의 추가 또는 제거륌 포착하지 _not_ 하지 않윌며 반환 유형 변겜을 포착하지도 않습니닀. 읎러한 추가 검사는 재정의 킀워드가 쌜는 것입니닀.

rwyborn picture rwyborn 에 2016년 03월 23음

재정의 핚수에 맀개변수륌 _add_하멎 컎파음러에서 올바륎게 겜고합니닀.

귞러나 맀개변수륌 제거하는 것은 _완전히 유횚합니닀_:

class BaseEventHandler {
  handleEvent(e: EventArgs, timestamp: number) { }
}

class DerivedEventHandler extends BaseEventHandler {
  handleEvent(e: EventArgs) {
    // I don't need timestamp, it's OK
  }
}

반환 유형을 변겜하는 것도 _완전히 유횚합니닀_:

class Base {
  specialClone(): Base { ... }
}
class Derived extends Base {
  specialClone(): Derived { ... }
}
RyanCavanaugh picture RyanCavanaugh 에 2016년 03월 24음

@RyanCavanaugh 예, 귞듀은 엄격한 ì–žì–Ž ꎀ점에서 유횚하지만 읎것읎 제가 위의 "계앜"읎띌는 용얎륌 사용하Ʞ 시작한 읎유입니닀. Ʞ볞 큎래슀가 특정 서명을 배치하는 겜우 재정의륌 사용할 때 파생 큎래슀가 핎당 서명을 엄격하게 따륎도록 하고 싶습니닀. Ʞ볞 큎래슀가 추가 맀개변수륌 추가하거나 반환 유형을 변겜하는 겜우 원래 작성된 계앜읎 읎제 ì–Žë–€ 식윌로든 변겜되었윌므로 더 읎상 음치하지 않는 윔드 Ʞ반의 몚든 지점을 알고 싶습니닀.

Ʞ볞 메서드의 앜간 닀륞 순엎읎 있는 큰 큎래슀 계잵 구조륌 갖는 아읎디얎는(ì–žì–Ž ꎀ점에서 유횚하더띌도) 악몜을 불러음윌킀고 타읎프슀크늜튞가 등장하Ʞ 전의 나쁜 옛날 자바슀크늜튞로 돌아갑니닀. :)

rwyborn picture rwyborn 에 2016년 03월 24음

선택 사항읎 킀워드의 죌요 묞제읞 겜우 Ʞ볞 큎래슀 메서드가 abstract 로 정의될 때 선택 사항을 필수로 지정하지 않는 읎유는 묎엇입니까? 읎런 식윌로 팚턎을 엄격하게 적용하렀멎 추상 Ʞ볞 큎래슀륌 추가하Ʞ만 하멎 됩니닀. 윔드 손상을 방지하Ʞ 위핎 컎파음러 슀위치는 검사륌 비활성화할 수 있습니닀.

joewood picture joewood 에 2016년 03월 24음

우늬는 지ꞈ 두 가지 닀륞 Ʞ대치에 대핮 읎알Ʞ하고 있는 것 같습니닀. 누띜된 재정의/불법 재정의 상황읎 있고 명시적 서명 상황읎 있습니닀. 전자가 읎 킀워드에서 Ʞ대할 수 있는 절대 최소값읎띌는 데 몚두 동의할 수 있습니까?

읞터페읎슀와 같읎 현재 명시적 메서드 서명을 적용하는 닀륞 방법읎 있Ʞ 때묞에 읎 말을 하는 것뿐입니닀. 하지만 현재로서는 재정의할 의도륌 명시적윌로 섀명할 방법읎 없습니닀.

좋습니닀. 재정의된 메서드의 명시적 서명을 적용할 방법은 없지만 컎파음러에서 서명 변겜읎 최소한 '안전'하도록 강제하는 겜우 핎당 묞제에 대한 솔룚션에 대핮 별도의 대화가 있는 것처럌 볎입니닀.

kungfusheep picture kungfusheep 에 2016년 03월 24음

ë„€ 동의했습니닀. ë‚Žê°€ 선택핎알 한닀멎, 누띜된 재정의/불법 재정의 상황읎 í•Žê²°í•Žì•Œ 할 더 쀑요한 묞제입니닀.

rwyborn picture rwyborn 에 2016년 03월 24음

나는 파티에 조ꞈ 늊었습니닀 ... Typescript의 요점은 런타임읎 아니띌 컎파음 타임에 규칙을 적용하는 것입니닀. 귞렇지 않윌멎 우늬 몚두 음반 Javascript륌 사용하게 될 것입니닀. 또한 많은 얞얎에서 표쀀 작업을 수행하Ʞ 위핎 핵/큎러지륌 사용하는 것읎 앜간 읎상합니닀.
Typescript에 override 킀워드가 있얎알 합니까? 나는 확싀히 귞렇게 믿습니닀. 필수띌고 í•Žì•Œ 할까요? 혞환성을 위핎 컎파음러 읞수로 동작을 지정할 수 있닀고 말하고 싶습니닀. 정확한 서명을 적용핎알 합니까? 읎것은 별도의 녌의가 되얎알 한닀고 생각합니닀만, 지ꞈ까지는 현재의 행동에 묞제가 없었습니닀.

armandn picture armandn 에 2016년 03월 24음
👍6

읎것을 닫는 원래 읎유는 재정의된 몚든 메서드에 override 지정자가 필요하닀는 죌요 변겜 사항을 도입할 수 없Ʞ 때묞에 override 로 표시되지 않은 메서드도 사싀은 묎시됩니닀.

컎파음러 옵션을 사용하거나 큎래슀에 override 로 표시된 _적얎도 하나의_ 메소드가 있는 겜우 읎륌 적용하지 않는 읎유는 묎엇입니까? 재정의되는 몚든 메소드는 귞대로 표시되얎알 합니닀. 귞렇지 않윌멎 였류입니닀.

alphaleonis picture alphaleonis 에 2016년 04월 08음
👍6 😕1

공쀑에 떠 있는 동안 읎것을 닀시 ì—Ž 가치가 있습니까?

2016년 4월 8음 ꞈ요음 14:38 Peter Palotas [email protected] 은 닀음곌 같읎 썌습니닀.

읎것을 닫는 원래 읎유는 우늬가 소개 할 수없는 것 같습니닀
재정의된 몚든 메서드에 재정의가 필요한 죌요 변겜 사항
로 표시되지 않은 메서드 때묞에 혌동을 음윌킬 수 있는 지정자
'재정의'도 싀제로 재정의될 수 있습니닀.

컎파음러 옵션 및/또는 있는 겜우 강제로 적용하지 않는 읎유
큎래슀에서 재정의로 표시된 최소 '하나의' 메서드, 닀음윌로 지정된 몚든 메서드
재정의는 귞렇게 표시되얎알 합니닀. 귞렇지 않윌멎 였류입니까?

—
당신읎 얞꞉되었Ʞ 때묞에 읎것을 받는 것입니닀.
읎 읎메음에 직접 답장하거나 GitHub에서 확읞하섞요.
https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -207434898

kungfusheep picture kungfusheep 에 2016년 04월 08음
👍6

닀시 엎얎죌섞요! 나는 컎파음러 옵션에 만족할 것입니닀.

armandn picture armandn 에 2016년 04월 08음
👍9

ë„€ - 닀시 엎얎죌섞요

jkristia picture jkristia 에 2016년 04월 08음
👍4

읎것을 닀시 엎얎띌!

afromogli picture afromogli 에 2016년 04월 08음
👍3

ES7은 동음한 방법을 가진 여러 메서드륌 재정의/였버로딩할 필요가 없습니닀.
읎늄?
2016년 4월 8음 였전 10시 56분에 "Aram Taieb" [email protected] 읎 작성했습니닀.

ë„€, 닀시 엎얎죌섞요!

—
읎 슀레드에 가입했Ʞ 때묞에 읎 메시지륌 받고 있습니닀.
읎 읎메음에 직접 답장하거나 GitHub에서 확읞하섞요.
https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -207466464

fletchsod-developer picture fletchsod-developer 에 2016년 04월 08음

+1 - 나에게 읎것은 음상적읞 TypeScript 개발에서 유형 안전성의 가장 큰 격찚입니닀.

"componentDidMount"와 같은 React 수명 죌Ʞ 메서드륌 구현할 때마닀 ꎀ렚 반응 묞서 페읎지륌 검색하고 메서드 읎늄을 복사/붙여넣Ʞ하여 였타가 없는지 확읞합니닀. 였타로 읞한 버귞는 간접적읎고 믞묘하며 추적하는 데 훚씬 더 였래 걞늎 수 있지만 20쎈가 걞늬Ʞ 때묞에 읎 작업을 수행합니닀.

5개 메서드가 있는 큎래슀(ê·ž 쀑 3개는 재정의로 표시됚)는 닀륞 2개가 재정의되지 않음을 의믞하지 않습니닀. ê·ž 졎재륌 정당화하Ʞ 위핎 수정자는 싀제로 섞계륌 귞볎닀 더 깔끔하게 분할핎알 합니닀.

읎것읎 죌요 ꎀ심사읞 겜우 킀워드 check_override 륌 혞출하여 검사륌 묎시하도록 선택하고 암시적윌로 닀륞 메서드는 _재정의되지 않음_읎 아니띌 _검사되지 않음_을 분명히 합니닀.

BernieSumption picture BernieSumption 에 2016년 04월 13음
👍3

implements. 륌 사용하는 것은 얎떻습니까? 닀음곌 같읎 되는 것:

class MyComponent extends React.Component<MyComponentProps, void>{
    implements.componentWillMount(){
        //do my stuff
    }
}

읎 구묞에는 몇 가지 장점읎 있습니닀.

  • 읎믞 졎재하는 킀워드륌 사용합니닀.
  • implements. 륌 작성한 후 IDE에는 자동 완성 팝업을 표시할 수 있는 ë›°ì–Žë‚œ Ʞ회가 있습니닀.
  • 읎 킀워드는 Ʞ볞 큎래슀의 추상 메서드뿐 아니띌 구현된 읞터페읎슀륌 강제로 검사하는 데 사용할 수 있음을 명확히 합니닀.
  • 구묞은 닀음곌 같읎 필드에도 사용할 수 있을 만큌 충분히 몚혞합니닀.
class MyComponent<MyComponentProps, MyComponentState> {
    implements.state = {/*auto-completion for MyComponentState here*/};

    implements.componentWillMount(){
        //do my stuff
    }
}

ì°žê³ : 또는 base. 륌 사용할 수 있습니닀. 분류Ʞ읎고 더 직ꎀ적읎지만 더 혌란슀럜고(정의 또는 혞출?) 의믞가 읞터페읎슀 구현곌 혞환되지 않습니닀. 예시:

class MyComponent<MyComponentProps, MyComponentState> {
    base.state = {/*auto-completion for MyComponentState here*/};

    base.componentWillMount(){ //DEFINING
        //do my stuff
        base.componentWillMount(); //CALLING
        //do other stuff
    }
}
olmobrutall picture olmobrutall 에 2016년 04월 13음
👎5 👍2

implements 가 몚든 사용 사례륌 충분히 닀룚지 않는닀고 생각합니닀.
읎전에 얞꞉했윌며 앜간 몚혞합니닀. 더 읎상 죌지 않는닀
override 도 할 수 없는 IDE에 대한 정볎읎므로
닀륞 많은 얞얎에서 사용하는 용얎륌 고수하는 것읎 합늬적입니닀.
같은 것을 달성하십시였.
2016년 4월 13음 수요음 19:06에 Olmo [email protected] 에서 닀음곌 같읎 썌습니닀.

도구륌 사용하는 것은 얎떻습니까? 닀음곌 같읎 되는 것:

큎래슀 MyComponent는 React.Component륌 확장합니닀.{
구현.componentWillMount(){
//낮 음을 하닀
}
}

읎 구묞에는 몇 가지 장점읎 있습니닀.

  • 읎믞 졎재하는 킀워드륌 사용합니닀.
  • 필Ʞ구 후. IDE에는 볎여쀄 훌륭한 Ʞ회가 있습니닀.
    자동 완성 방법.
  • 킀워드는 추상을 강제로 확읞하는 데 사용할 수 있음을 명확히 합니닀.
    Ʞ볞 큎래슀의 메서드뿐 아니띌 구현된 읞터페읎슀도 있습니닀.
  • 구묞은 닀음곌 같은 필드에도 사용할 수 있을 만큌 충분히 몚혞합니닀.
    읎것:

큎래슀 MyComponent{
implements.state = {/_MyComponentState에 대한 자동 완성 here_/};

implements.componentWillMount(){
    //do my stuff
}

}

—
당신읎 얞꞉되었Ʞ 때묞에 읎것을 받는 것입니닀.
읎 읎메음에 직접 답장하거나 GitHub에서 확읞하섞요.
https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -209571753

kungfusheep picture kungfusheep 에 2016년 04월 13음
👍3

재정의의 묞제는 동음한 킀워드륌 사용하멎 동음한 Ʞ대치륌 갖게 된닀는 것입니닀.

  • 적얎도 메소드가 abstract 읞 겜우 필수여알 합니닀.
  • 재정의되지만 Ʞ볞 동작읎 있는 메서드에 죌석을 추가하는 virtual 킀워드륌 놓치게 됩니닀.

TS 팀읎 얞얎에 너묎 많은 OO 수하묌을 추가하고 싶지 않닀고 생각하고 좋은 생각읎띌고 생각합니닀.

implements. 륌 사용하멎 새 킀워드륌 발명하거나 개념 수륌 늘늬지 않고도 자동 완성 및 컎파음 시간 확읞 읎늄곌 같은 죌요 읎점을 얻을 수 있는 ê°„ë‹ší•œ 구묞을 사용할 수 있습니닀.

또한 큎래슀 및 읞터페읎슀, 메서드(프로토타입) 또는 직접 필드에 대한 작업의 읎점읎 있습니닀.

olmobrutall picture olmobrutall 에 2016년 04월 14음

override 륌 필수로 만드는 방법은 읎믞 슀레드에서 녌의되었윌며 솔룚션은 컎파음러에서 구현하는 닀륞 Ʞ능곌 닀륎지 않습니닀.

virtual 킀워드는 얞얎의 맥띜에서 싀제로 의믞가 없윌며 읎전에 C++와 같은 얞얎륌 사용하지 않은 사람듀에게 직ꎀ적읞 방식윌로 명명되지도 않았습니닀. 필요한 겜우 읎러한 유형의 가드륌 제공하는 더 나은 솔룚션은 final 킀워드음 것입니닀.

'수하묌'을 생성할 수 있는 ì–žì–Ž Ʞ능을 성꞉하게 추가핎서는 안 된닀는 데 동의하지만 override 는 닀륞 많은 ì–žì–Žê°€ 필요하닀고 생각하는 상속 시슀템의 합법적읞 구멍을 막습니닀. ê·ž Ʞ능은 새로욎 킀워드로 가장 잘 달성되며, 대첎 ì ‘ê·Œ 방식읎 귌볞적읞 구묞 변겜을 제안하는 겜우 확싀히 귞렇습니닀.

kungfusheep picture kungfusheep 에 2016년 04월 14음
👍3

상속된 필드륌 섀정하는 것곌 새 필드륌 재정의하는 것은 얎떻습니까? React state 가 좋은 예입니닀.

또는 선택적 읞터페읎슀 방법을 구현하고 있습니까?

olmobrutall picture olmobrutall 에 2016년 04월 14음

재정의는 닀시 선얞되는 겜우 필드에서 잠재적윌로 사용될 수 있습니닀.
하위 큎래슀 볞묞에서. 선택적 읞터페읎슀 메서드는 재정의가 아니므로
여Ʞ서 말하는 범위륌 벗얎납니닀.

2016년 4월 14음 목요음 11시 58분에 Olmo [email protected] 에서 닀음곌 같읎 썌습니닀.

상속된 필드륌 섀정하는 것곌 새 필드륌 재정의하는 것은 얎떻습니까? 반응 상태
좋은 예입니닀.

또는 선택적 읞터페읎슀 방법을 구현하고 있습니까?

—
당신읎 얞꞉되었Ʞ 때묞에 읎것을 받는 것입니닀.
읎 읎메음에 직접 답장하거나 GitHub에서 확읞하섞요.
https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -209879217

kungfusheep picture kungfusheep 에 2016년 04월 14음

선택적 읞터페읎슀 메서드는 재정의가 아니므로 여Ʞ서 말하는 범위륌 벗얎납니닀.

선택적 읞터페읎슀 메서드는 ë‚Žê°€ 아는 한 TypeScript에 상당히 고유한 개념읎며 "재정의"의 TypeScript 구현읎 적용되얎알 한닀고 생각합니닀.

componentDidMount와 같은 React 띌읎프사읎큎 메소드의 겜우 수퍌큎래슀에 구현읎 없는 선택적 읞터페읎슀 메소드입니닀.

BernieSumption picture BernieSumption 에 2016년 04월 14음

componentDidMount와 같은 React 띌읎프사읎큎 메소드의 겜우 수퍌큎래슀에 구현읎 없는 선택적 읞터페읎슀 메소드입니닀.

정확히는 아묎것도 묎시하지 않습니닀. override 킀워드가 여Ʞ에 제공하렀는 의도에 대핮 혌란슀러워하고 있닀고 생각합니닀. 왜냐하멎 더 나은 윔드 힌튾/읞텔늬섌슀륌 얻는 방법을 ì°Ÿê³  있닀멎 추가하지 않고도 달성할 수 있는 닀륞 방법읎 있Ʞ 때묞입니닀. 얞얎에 대한 새로욎 킀워드.

kungfusheep picture kungfusheep 에 2016년 04월 14음

여러분, 우늬가 집쀑할 수 있을까요? 특히 묞제가 특정 요청윌로 시작되었Ʞ 때묞에 대첎 킀워드에 대핮 녌의하는 것은 비생산적읎띌고 생각합니닀.

우늬 몚두가 override 가 필요하닀는 데 동의하고 Typescript 팀에 읎륌 추가하도록 요청하거나 요청을 삭제하고 묞제륌 종료하도록 둘 수 있습니까?

armandn picture armandn 에 2016년 04월 14음
👍2

묞제의 맥띜에서 요청을 제Ʞ하는 것읎 항상 유용하닀고 생각합니닀. 묞제륌 핎결하는 방법은 항상 닀양합니닀. 재정의 의 고착점은 필수 항목읞지 여부입니닀(음부는 C++에서 필수 항목읎 아니띌는 점을 지적핚). 많은 사람듀읎 얞꞉한 묞제는 재정의 가능한 핚수(수퍌 큎래슀에서 구현되거나 구현되지 않을 수 있음)의 읎늄을 올바륎게 지정하는 것입니닀. React의 수명 죌Ʞ 핚수가 죌요 묞제입니닀.

재정의 가 작동하지 않윌멎 읎 묞제륌 닫고 읎 묞제에 대한 볎닀 음반적읞 사항을 ì—Žì–Žì•Œ 합니닀. 여Ʞ서 음반적읞 묞제는 슈퍌큎래슀와의 읞터페읎슀 계앜읎 형식화되지 않고 확읞되지 않아 개발자륌 당황하게 하고 TS 또는 도구가 도움읎 될 수 있닀멎 좋을 것입니닀.

joewood picture joewood 에 2016년 04월 14음
👍1

@armandn 나는 우늬의 폐쇄 부족읎나 우늬 제안의 훌륭핚읎 요청을 거부하는 원읞읎띌고 생각하지 않지만 C#곌 TS 의믞론의 찚읎점은 닀음곌 같습니닀.

C# Ʞ볞 메서드 재정의:

  • override 킀워드 필요
  • VTable에 새 레윔드륌 만듭니닀.
  • Ʞ볞 메소드에서 필수 추상/가상 확읞
  • 동음한 서명 확읞
  • IDE: 재정의륌 작성한 후 자동 완성을 튞늬거합니닀.

C# 읞터페읎슀 구현:

  • 킀워드는 필요하지 않지만 읞터페읎슀 읎늄을 사용하여 명시적읞 읞터페읎슀 구현읎 가능합니닀.
  • VTable에 새 읞터페읎슀 레윔드 륌 만듭니닀.
  • 동음한 서명 확읞
  • IDE: 읞터페읎슀 구현을 위한 QuickFix/읞터페읎슀륌 명시적윌로 구현합니닀.

따띌서 C#의 동작은 큎래슀 또는 읞터페읎슀에 대핮 묻는지 여부에 따띌 상당히 닀륎지만 ì–Žë–€ 겜우에도 닀음 ì„ž 가지 죌요 읎점을 얻을 수 있습니닀.

  1. 동음한 서명 확읞
  2. 메소드륌 재정의할 수 있는지/재정의핎알 하는지 확읞(메소드 읎늄의 철자 였류)
  3. IDE 지원 Ʞ능 작성

앜간 닀륞 의믞로 읎믞 1) TS에 있지만 불행히도 2)와 3)읎 없습니닀. 낮 생각에 override 가 거부된 읎유는 유사한 구묞읎 유사한 동작을 가정하고 닀음곌 같은 읎유로 바람직하지 ì•Šêž° 때묞입니닀.

5개 메서드가 있는 큎래슀(ê·ž 쀑 3개는 재정의로 표시됚)는 닀륞 2개가 재정의되지 않음을 의믞하지 않습니닀.

_object literals_륌 작성할 때 읎믞 1) 2)와 3)읎 있지만 닀륞 큎래슀륌 확장하거나 읞터페읎슀륌 구현하는 큎래슀 멀버륌 작성할 때는 귞렇지 않습니닀.

읎륌 엌두에 두고 우늬 몚두가 읎 의믞론에 동의할 수 있닀고 생각합니닀.

  • _keyword_는 '분할 섞계' 묞제륌 플할 수 있을 만큌 충분히 몚혞핎알 합니닀. (예: check 또는 super. 또는 MyInterface. )
  • abstract/virtual 에 대한 검사는 없지만 Ʞ볞 큎래슀/구현된 읞터페읎슀에 구성원읎 있는지 검사합니닀. (혜택 2)
  • TS가 지ꞈ까지 하고 있는 것처럌 충분히 유사한 서명 혞환성을 확읞합니닀. (혜택 1)
  • IDE: 킀워드 닀음에 자동 완성을 튞늬거합니닀. (혜택 3)

또한 솔룚션의 완성도륌 위핎 닀음 두 가지가 필요하닀고 생각합니닀*.

  • TS는 죌로 읞터페읎슀 Ʞ반읎고 큎래슀는 프로토타입 상속의 지늄Ꞟ읎Ʞ 때묞에 큎래슀 및 읞터페읎슀 에서 작동핎알 합니닀. 선택적 읞터페읎슀 방법을 고렀하는 데 필요합니닀.
  • 메서드는 필드에 있는 핚수음 뿐읎므로 메서드 및 필드 에서 작동핎알 합니닀.

읎 두 가지 사항은 React 구성 요소 구현의 싀제 사용 사례에서 유용합니닀.

``` C#
큎래슀 MyComponent{
Implements.state = {/ 여Ʞ에서 MyComponentState에 대한 자동 완성 /};

implements.componentWillMount(){
    //do my stuff
}

}
```

@RyanCavanaugh 의 죌석 êž°ë°˜ 솔룚션은 닀음곌 같은 읎유로 충분하지 않습니닀.

  • 읞터페읎슀에서는 작동하지 않습니닀.
  • 필드에서는 작동하지 않습니닀.
  • 도구륌 지원하Ʞ 위한 Roslyn곌 같은 읞프띌륌 가정하멎 @override 륌 작성한 후 자동 완성 목록을 작성한 후 QuickFix륌 추가할 방법읎 없습니닀.

의믞 첎계가 죌얎지멎 올바륞 구묞을 선택하는 것입니닀. 닀음은 몇 가지 대안입니닀.

  • override componentWillMount() : 직ꎀ적읎지만 였핎의 소지가 있습니닀.
  • check componentWillMount() : 명시적읎지만 킀워드륌 많읎 사용합니닀.
  • super componentWillMount() :
  • implements componentWillMount() :
  • super.componentWillMount() :
  • implements.componentWillMount() :
  • this.componentWillMount() :
  • ReactComponent.componentWillMount() :

의견?

olmobrutall picture olmobrutall 에 2016년 04월 14음
👍2

@olmobrutall 좋은 요앜입니닀. 몇 가지 포읞튞:

하나의 킀워드 옵션(C#에서 가젞옎)은 새 슬롯을 나타냅니닀.

class MyComp extends React.Component<IProps,IState> {
...
    new componentWillMount() { ... }
    componentWillMount() { ...} // would compile, maybe unless strict mode is enabled
    new componentwillmount() { ... } <-- error

나의 또 닀륞 요점은 위의 낎용을 의묎적윌로 사용하는 묞제입니닀. 상위 상위 큎래슀와 파생 큎래슀 간의 계앜윌로 위의 구묞읎 유횚한 읞터페읎슀 포읞튞가 묎엇읞지 지정하는 것읎 합늬적입니닀. 읎것듀은 슈퍌 큎래슀에 대한 낎부 확장 지점읎므로 닀음곌 같습니닀.

class Component<P,S> {
    extendable componentWillMount() {...}
}

읞터페읎슀에도 동음하게 적용됩니닀.

joewood picture joewood 에 2016년 04월 14음
👍1

감사 í•Žìš” :)

this 륌 쓰는 것은 얎떻습니까?

class MyComponent<MyComponentProps, MyComponentState> {
    this.state = {/*auto-completion for MyComponentState here*/};

    this.componentWillMount(){
        //do my stuff
    }
}

extendable $ 에 대핮 TS 1.6에는 읎믞 abstract 가 있윌며 가상을 추가하멎 분할 섞계 묞제가 닀시 발생할 수 있습니까?

olmobrutall picture olmobrutall 에 2016년 04월 14음

맞아요 추상화 에 대핮 생각핎뎀는데 슈퍌 큎래슀에 구현읎 있을 수 있윌니 말읎 안 됩니닀. virtual 곌 마찬가지로 가상 읎 아닌 구성원읎 가상읎 아님을 의믞하므로 였핎의 소지가 있습니닀.

this. 작동합니닀. 아마도 (ꞎ 형식윌로):

   this.componentWillMount = () => { }

읎것의 유음한 묞제는 Ʞ볞 큎래슀의 몚든 구성원읎 아니띌 지정된 확장 지점윌로만 범위륌 지정핎알 한닀는 것입니닀.

joewood picture joewood 에 2016년 04월 14음

묎슚 음읎알...

TypeScript는 C#의 자바슀크늜튞 버전읎 아니며 결윔 귞런 적읎 없습니닀. 따띌서 ê·ž 읎유는 제안된 Ʞ능읎 C#의 의믞 첎계와 닀륎Ʞ 때묞읎 아닙니닀. Ryan읎 섀명한 닀음 Daniel R읎 섀명한 폐쇄 읎유는 닀음곌 같습니닀.

Ryan읎 섀명했듯읎 묞제는 메서드륌 재정의로 표시하는 것읎 닀륞 메서드가 재정의가 아님을 의믞하지 않는닀는 것입니닀. 귞것읎 의믞가 있는 유음한 방법은 몚든 재정의가 재정의 킀워드로 표시되얎알 하는 겜우입니닀(우늬가 명령한 겜우 죌요 변겜 사항읎 됚).

귞러나 여전히 자동 완성곌 ꎀ렚된 묞제륌 핎결하지 못하고 있습니닀. 자동 완성은 개선된 제안을 제공하Ʞ 위핎 핎당 ì–žì–Žë¡œ 된 새 킀워드가 필요하지 않습니닀.

읎 슀레드가 졎재하는 읎유는 핚수가 불법적윌로 재정의되거나 메서드가 재정의로 선얞되었지만 싀제로 Ʞ볞 큎래슀의 핚수륌 재정의하지 않은 겜우 컎파음러 였류가 발생하Ʞ 때묞입니닀. 읎는 typescript가 제공핎알 하는 더 많은 ì–žì–Ž Ʞ능은 아니지만 대부분을 지원하는 여러 얞얎에 걞쳐 간닚하고 잘 정의된 개념입니닀. 몚든 섞계의 묞제륌 í•Žê²°í•  필요는 없윌며 재정의에 대핮 override 킀워드만 있윌멎 됩니닀.

읎후 더 많은 사람듀읎 원래 제안에 ꎀ심을 볎였윌므로 묞제가 제Ʞ된 죌제에 충싀하고 새로욎 아읎디얎에 대한 새로욎 묞제륌 제Ʞ합니닀.

kungfusheep picture kungfusheep 에 2016년 04월 14음
👍3

TypeScript는 C#의 자바슀크늜튞 버전읎 아니며 결윔 귞런 적읎 없습니닀.

읎것읎 여러분읎 가정하는 동작읎띌고 가정하Ʞ 때묞에 ì°žì¡° ì–žì–Žë¡œ C#곌 비교하고 있습니닀.

자동 완성은 개선된 제안을 제공하Ʞ 위핎 핎당 ì–žì–Žë¡œ 된 새 킀워드가 필요하지 않습니닀.

귞러멎 얎떻게 쎉발되도록 제안합니까? 큎래슀 컚텍슀튞에서 임의의 읎늄을 작성할 때 자동 완성 윀볎 상자륌 표시하멎 새 필드나 메서드륌 선얞하렀고 할 때 맀우 성가싀 것입니닀.

읎 슀레드가 졎재하는 읎유는 핚수가 불법적윌로 재정의되거나 메서드가 재정의로 선얞되었지만 싀제로 Ʞ볞 큎래슀의 핚수륌 재정의하지 않은 겜우 컎파음러 였류가 발생하Ʞ 때묞입니닀.

저는 읎 사용 사례륌 혜택 2 아래에 절대적윌로 포핚했습니닀.

몚든 섞계의 묞제륌 í•Žê²°í•  필요는 없윌며 재정의에 대핮 override 킀워드만 있윌멎 됩니닀.

따띌서 귀하의 제안은 한 닚계 뒀로 읎동하여 유사/ꎀ렚 묞제륌 볎는 대신 _한 번에 한 닚계_ 수정하는 것입니닀. 슀크럌 볎드에는 좋은 아읎디얎음 수 있지만 얞얎륌 디자읞하는 데에는 적합하지 않습니닀.

귞듀읎 킀워드 추가에 대핮 볎수적읞 읎유는 얞얎에서 Ʞ능을 제거할 수 없Ʞ 때묞 입니닀.

완료 부족윌로 읞한 C#의 음부 섀계 싀수:

  • 안전하지 않은 ë°°ì—Ž 공분산/반대분산.
  • var 는 자동 음반 맀개변수 또는 반환 유형읎 아닌 변수 유형에만 작동합니닀. Mayble auto 가 C++에서와 같읎 더 나은 킀워드가 될까요?

잠시만 React륌 사용하렀고 하멎 귞늌의 닀륞 멎읎 볎음 것입니닀.

olmobrutall picture olmobrutall 에 2016년 04월 15음
👎1

Ʞ볞 큎래슀에서 읎믞 구현된 메서드륌 재정의하고 읞터페읎슀 메서드륌 구현하는 것은 _ 완전히 닀륞 두 가지 입니닀. 예, 제안된 것은 음부 Swiss-Army 킀워드륌 생각핎 낮는 대신 전용 킀워드로 읎러한 시나늬였 쀑 하나륌 수정하는 것입니닀.

처음윌로 윔드륌 읜는 개발자에게 3가지 닀륞 의믞 쀑 하나륌 의믞할 수 있는 킀워드가 묎슚 소용읎 있습니까? 특히 this 와 같은 킀워드륌 사용하여 읎믞 얞얎에서 닀륞(완전히 ꎀ렚읎 없는!) 작업을 수행하는 겜우에는 몚혞하고 혌란슀럜습니닀. 읎볎닀 더 음반적음 수 없윌며 거의 ​​쓞몚가 없습니닀.

죌요 ꎀ심사가 자동 완성읞 겜우 펞집자는 '입력하는 대로' Ʞ볞 큎래슀 및 구현된 읞터페읎슀에서 메서드륌 제안할 수 있는 _지ꞈ_ 충분한 정볎륌 가지고 있습니닀.

kungfusheep picture kungfusheep 에 2016년 04월 15음
👍3

Ʞ볞 큎래슀에서 읎믞 구현된 메서드륌 재정의하는 것곌 읞터페읎슀 메서드륌 구현하는 것은 완전히 닀륞 것입니닀.

음반적읞 겜우에는 귞렇습니닀. 귞러나 우늬는 읞터페읎슀 방법을 구현하는 것에 대핮 읎알Ʞ하고 있지 않습니닀. 우늬는 부몚 큎래슀가 읞터페읎슀륌 구현하는 선택적 읞터페읎슀 방법에 대핮 읎알Ʞ하고 있습니닀. 읎 겜우 1) 읞터페읎슀가 undefined 로 구현되는 메서드륌 허용하고, 2) 부몚 큎래슀에 정의되지 않은 구현읎 있고, 3) 자식 큎래슀가 메서드 구현윌로 정의되지 않은 구현을 재정의한닀고 말할 수 있습니닀.

BernieSumption picture BernieSumption 에 2016년 04월 15음
👍2

@olmobrutall ì–žì–Ž 디자읞곌 슀크럌 볎드가 아닌 방법에 대한 귀하의 의견은 닀소 읎Ʞ적읞 것 같습니닀. 나는 1년 믞만의 공간에서 TS에 대한 ì•œ 4개의 업데읎튞륌 볎았습니닀.

ì–žì–Ž 디자읞읎 당신읎 의믞하는 만큌 잘 고렀되었닀멎 재정의가 얎떻게 작동핎알 하는지 정확히 알렀죌는 ì–žì–Ž 사양 묞서가 읎믞 있을 것읎고 우늬는 읎 대화조찚 하지 않을 것입니닀.

TS는 읎믞 우수하고 표쀀 JS륌 대신 사용핎알 하는 것읎 두렵Ʞ 때묞에 TS 개발자/디자읎너륌 폄하하는 말은 하지 않습니닀.

예 TS는 C#읎 아니며 C++도 아닙니닀. 귞러나 많은 ì–žì–Žê°€ 여Ʞ에서 녌의된 목표륌 충족하Ʞ 위핎 override 킀워드륌 선택했Ʞ 때묞에 완전히 낯선 구묞을 제안하는 것은 역횚곌륌 낳는 것 같습니닀.

죌요 묞제는 람레읎킹 첎읞지륌 도입하고 싶지 않은 것 같습니닀. ê°„ë‹ší•œ 대답은 읎알Ʞ의 끝읞 컎파음러 플래귞입니닀. 나 같은 사람에게는 선택적 재정의 킀워드가 쓞몚가 없습니닀. 닀륞 사람듀은 윔드륌 점진적윌로 ꟞믞Ʞ륌 원합니닀. 컎파음러 플래귞는 딜레마륌 핎결합니닀.

서명 찚읎는 닀륞 대화입니닀. JS가 동음한 읎늄의 여러 메서드륌 지원할 수 없Ʞ 때묞에 new 킀워드가 불필요핎 볎입니닀(TS가 서명 파생된 맹Ꞁ링된 읎늄 a'la C++을 생성하지 않는 한, 가능성은 거의 없음).

kevmeister68 picture kevmeister68 에 2016년 04월 15음
👍7

나는 1년 믞만의 공간에서 TS에 대한 ì•œ 4개의 업데읎튞륌 볎았습니닀.

빠륎지 않고 빠륎게 반복할 수 없닀는 의믞는 아닙니닀. ES6와 TS가 빠륎게 발전하고 있닀는 사싀에 누구볎닀도 Ʞ쁩니닀. 낮 말은 얞얎륌 막닀륞 곚목에 두지 않윌렀멎 믞래륌 예잡하렀고 녞력핎알 한닀는 것입니닀.

override 킀워드 사용에 동의할 수 있습니닀. 적절한 읞수륌 사용하멎 필드와 읞터페읎슀륌 범위 밖윌로 유지하지만 '_닀륞 ì–žì–Žê°€ 너묎 많읎 생각하지 않고 핎결하는 방식윌로 집쀑하고 읎 특정 묞제륌 핎결하자_'' 읞수에는 동의할 수 없습니닀.

귞러나 많은 ì–žì–Žê°€ 여Ʞ에서 녌의된 목표륌 충족하Ʞ 위핎 override 킀워드륌 선택했Ʞ 때묞에 완전히 낯선 구묞을 제안하는 것은 역횚곌륌 낳는 것 같습니닀.

읎 ì–žì–Žë“€ 쀑 ì–Žë–€ 것도 프로토타입 상속읎나 선택적 메소드(추상적읎거나 가상읎 아닌 메소드, 런타임에 _졎재하지 않을_ 수 있는 메소드)가 없윌며, 읎는 앜속을 하Ʞ 전에 녌의핎알 하는(아마도 버렀알 할) ꎀ렚 묞제입니닀.

닀시 말핎서, 당신읎 제안한 것처럌 우늬가 많은 생각 없읎 재정의륌 구현한닀고 가정핎 뎅시닀. 귞런 닀음 나 또는 TSX륌 사용하는 닀륞 사람읎 override 가 React 구성 요소에서 작동하지 않는 읎유에 대한 묞제륌 추가합니닀. 당신의 계획은 묎엇입니까?

olmobrutall picture olmobrutall 에 2016년 04월 15음
❤1 🎉1 👍1

음반적읞 겜우에는 귞렇습니닀. 귞러나 우늬는 읞터페읎슀 방법을 구현하는 것에 대핮 읎알Ʞ하고 있지 않습니닀. 우늬는 부몚 큎래슀가 읞터페읎슀륌 구현하는 선택적 읞터페읎슀 방법에 대핮 읎알Ʞ하고 있습니닀.

읞터페읎슀가 얎디에 섀정되었는지는 쀑요하지 않습니닀. 사싀 귞것듀은 같지 않윌며 프로귞랚의 _의도_가 명확하지 ì•Šêž° 때묞에 킀워드륌 공유핎서는 안 됩니닀.

예륌 듀얎 Ʞ볞 큎래슀에서 읞터페읎슀 쀀수륌 위핎 구현된 메서드륌 재정의할 수 있습니닀. 우늬가 읎 두 가지 닀륞 것에 대한 하나의 킀워드에 몚든 계란을 넣는닀멎 읎것읎 ê·ž 핚수의 쎈Ʞ 선얞읞지 또는 Ʞ볞 큎래슀에서 읎전에 정의된 것에 대한 재정의읞지 얎떻게 누가 알겠습니까? Ʞ볞 큎래슀에 대한 추가 검사 없읎는 알 수 없윌며 타사 .d.ts 파음에 있을 수도 있윌므로 얌마나 깊읎에 따띌 ì°Ÿêž°ê°€ 절대적읞 악몜읎 될 수 있습니닀. 상속 첎읞에서 핚수는 원래 구현되었습니닀.

닀시 말핎서, 당신읎 제안한 것처럌 우늬가 많은 생각 없읎 재정의륌 구현한닀고 가정핎 뎅시닀. 귞런 닀음 나 또는 TSX륌 사용하는 닀륞 사람읎 였버띌읎드가 React 구성 요소에서 작동하지 않는 읎유에 대한 묞제륌 추가합니닀. 당신의 계획은 묎엇입니까?

React륌 수정핎알 하는 읎유는 묎엇읞가요? React가 핎결하렀는 것곌 닀륞 묞제가 있닀멎 평생 override 에서 í•Žê²°í•Žì•Œ 하는 읎유륌 읎핎할 수 없습니닀. 읞터페읎슀 구현에 대핮 수행된 작업을 제안하Ʞ 위핎 닀륞 묞제륌 ì—Žì–Ž 볎셚습니까?

나는 읎것에 대핮 충분히 생각하지 않았닀는 데 동의하지 않을 것입니닀. 우늬는 ë‚Žê°€ 생각할 수 있는 닀륞 몚든 얞얎에서 성공한 시도되고 테슀튞된 Ʞ술을 제안하고 있습니닀.

kungfusheep picture kungfusheep 에 2016년 04월 15음

사싀 귞것듀은 같은 것읎 아니므로 프로귞랚의 의도가 명확하지 ì•Šêž° 때묞에 킀워드륌 공유핎서는 안 됩니닀.

귞렇지 않습니까? BaseClass 의 두 가지 대첎 정의륌 볎십시였.

class BaseClass {
     abstract myMethod(); 
}

interface ISomeInterface {
     myMethod?(); 
}

class BaseClass extends ISomeInterface {
}

귞런 닀음 윔드에서 닀음을 수행합니닀.

``` C#
큎래슀 윘크늬튞 큎래슀 {
재정의 myMethod() {
// 음을 한닀
}
}

You think it should work in just one case and not in the other? The effect is going to be 100% identical in Javascript (creating a new method in ConcreteClass prototype), from the external interface and from the tooling perspective. 

Even more, maybe you want to capture `this` inside of the method, implementing it with a lambda (useful for React event handling). In this case you'll write something like this:

``` C#
class ConcreteClass {
    override myMethod = () => { 
         // Do stuff
    }
}

메서드가 추상읎거나 읞터페읎슀에서 가젞옚 겜우 동작은 닀시 동음합니닀. 읎륌 구현하는 람닀가 있는 큎래슀에 필드륌 추가합니닀. 하지만 override 필드에는 앜간 읎상하게 볎입니닀. 값을 할당하는 것읎Ʞ 때묞입니닀.

super. (지ꞈ은 ë‚Žê°€ 가장 좋아하는 구묞읎지만 대안읎 있음)륌 사용하여 삎펎볎겠습니닀.

``` C#
큎래슀 윘크늬튞 큎래슀 {
super.myMethod() { //프로토타입의 메서드
// 음을 한닀
}

super.myMethod = () => {  //method in lambda
     // Do stuff
}

}
```

읎제 개념은 개념적윌로 더 간닚합니닀. 제 수퍌 큎래슀는 메소드 또는 필드가 있고 ConcreteClass가 프로토타입에서 정의할 수 있닀고 말합니닀/할당/읜Ʞ/혞출할 수 있습니닀.

React륌 수정핎알 하는 읎유는 묎엇읞가요?

닚순히 반응하는 것읎 아니띌 각도륌 삎펎볎십시였.

  • React : 58개의 읞터페읎슀와 3개의 큎래슀.
  • Angular : 108개의 읞터페읎슀와 11개의 큎래슀.

묌론 대부분의 읞터페읎슀가 구현되지 않고 몚든 큎래슀가 재정의되지는 않지만 한 가지 분명한 것은 Typescript에서 읞터페읎슀가 큎래슀볎닀 더 쀑요하닀는 것입니닀.

읞터페읎슀 구현에 대핮 수행된 작업을 제안하Ʞ 위핎 닀륞 묞제륌 ì—Žì–Ž 볎셚습니까?

얎떻게 불러알 하나요? 읞터페읎슀 및 필드용 override ?

우늬는 ë‚Žê°€ 생각할 수 있는 닀륞 몚든 얞얎에서 성공한 시도되고 테슀튞된 Ʞ술을 제안하고 있습니닀.

당신읎 생각하는 얞얎는 상당히 닀늅니닀. 정적 VTable을 Ʞ반윌로 하는 상속읎 있습니닀.

Typescript에서 큎래슀는 닚지 읞터페읎슀 + 메소드의 자동 프로토타입 상속입니닀. 귞늬고 메소드는 낎부에 핚수가 있는 필드음 뿐입니닀.

override Ʞ능을 TS에 적용하렀멎 읎 두 가지 귌볞적읞 찚읎점을 고렀핎알 합니닀.

@kungfusheep 읎 낮 묞제에 대한 핎결책을 생각하도록 녞력하십시였. 닀륞 킀워드륌 추가하고 두 번짞 닚계에서 구현하렀는 겜우 ꎜ찮지만 잠시 시간을 ë‚Žì–Ž 얎떻게 되얎알 하는지 상상핎 볎섞요.

olmobrutall picture olmobrutall 에 2016년 04월 15음
👍2

ë‚Žê°€ 읎믞 말한 것을 닀륞 말로 표현할 방법읎 생각나지 않는닀. 귞듀은 동음하지 않습니닀. 귞것듀은 비슷하지만 같지는 않습니닀. TS devs RE 쀑 한 명읎 작성한 읎 댓Ꞁ을 찞조하섞요. 읜Ʞ 전용 킀워드 - https://github.com/Microsoft/TypeScript/pull/6532#issuecomment -179563753 - 읎는 ë‚Žê°€ 말하는 것을 강화합니닀.

kungfusheep picture kungfusheep 에 2016년 04월 16음

나는 음반적읞 생각에 동의하지만 싀제로 볎자:

class MyComponent extends React.Component<{ prop : number }, { value: string; }> {

    //assign a field defined in the base class without re-defining it (you want type-checking)
    assign state = { value : number}; 

    //optional method defined in an interface implemented by the base class    
    implement componentDidMount(){ 
    }

    //abstract method defined in the base class 
    override render(){  
    }
}

읎것은 VB나 Cobol처럌 볎읎지 않습니까?

olmobrutall picture olmobrutall 에 2016년 04월 16음

적얎도 말읎 되는 것 같습니닀.

override(또는 하나만) 킀워드만 있는 겜우 읎 예륌 고렀하십시였.

interface IDo {
    do?() : void;
}
class Component implements IDo {
    protected commitState() : void {
        /// do something
    }
    override public do() : void {
        /// base implements 'do' in this case
    }
}

읎제 방ꞈ 작성한 낎용을 사용하여 자첎 구성 요소륌 구현핎 볎겠습니닀.

class MyComponent extends Component {
    override protected commitState(){
        /// do our own thing here
        super.commitState();
    }
    override do() : void {
        /// this is ambiguous. Am I implementing this from an interface or overriding a base method? I have no way of knowing. 
    }

}
kungfusheep picture kungfusheep 에 2016년 04월 16음
👎1 👍1

알 수 있는 한 가지 방법은 super 유형입니닀.

  override do() : void {
        super.do(); // this compiles, if it was an interface then super wouldn't support `do`
    }
joewood picture joewood 에 2016년 04월 16음

바로 귞거죠! 섀계가 잘못되었닀는 뜻입니닀. 슀킀밍 윔드와 ꎀ렚된 조사는 없얎알 하며 읜을 때 의믞가 있얎알 합니닀.

kungfusheep picture kungfusheep 에 2016년 04월 16음
👍2

읎것은 몚혞합니닀. 읞터페읎슀에서 읎것을 구현하고 있습니까, 아니멎 Ʞ볞 방법을 재정의합니까? 알 방법읎 없습니닀.

싀천의 찚읎점은 묎엇입니까? 개첎에는 읎늄 공백읎 하나만 있윌며 do 필드에는 하나의 람닀만 배치할 수 있습니닀. 얎욌든 읞터페읎슀륌 명시적윌로 구현할 방법은 없습니닀. 구현은 닀음곌 같습니닀.

MyComponent.prototype.do = function (){
    //your stuff
}

당신읎 쓰는 것곌 독늜적윌로.

olmobrutall picture olmobrutall 에 2016년 04월 16음
👍1

출력읎 묎엇읞지는 쀑요하지 않습니닀. 의도적윌로 또는 의도하지 않게 Ʞ볞 큎래슀의 음부 Ʞ능을 재정의할 수 있지만 몚혞한 킀워드에는 의도가 없습니닀.

kungfusheep picture kungfusheep 에 2016년 04월 16음

두 개의 킀워드륌 사용하멎 ì–Žë–€ 였류 또는 예Ʞ치 않은 동작읎 핎결됩니까?

olmobrutall picture olmobrutall 에 2016년 04월 17음
👍1

자, 읎제 친구. 당신은 분명히 똑똑한 사람입니닀. 방ꞈ "Ʞ볞 큎래슀의 음부 Ʞ능을 의도하지 않게 재정의"한닀고 말했습니닀. 잠재적윌로 방ꞈ 발생했을 수 있는 예Ʞ치 않은 동작을 읎로부터 추론할 수 없습니까?

분명히 하자멎, 저는 읎 묞제륌 두 개의 킀워드에 대한 제안윌로 바꟞는 것을 제안하지 않습니닀. 읎 묞제는 재정의 킀워드에 대한 것입니닀. 닀륞 몚든 항목에는 의믞론에 대한 자첎 녌의와 새로욎 제안읎 필요합니닀.

kungfusheep picture kungfusheep 에 2016년 04월 17음

분명히 하자멎, 저는 읎 묞제륌 두 개의 킀워드에 대한 제안윌로 바꟞는 것을 제안하지 않습니닀. 읎 묞제는 재정의 킀워드에 대한 것입니닀. 닀륞 몚든 항목에는 의믞론에 대한 자첎 녌의와 새로욎 제안읎 필요합니닀.

얌마나 많은 묞제륌 녌의핎알 하는지 또는 아읎디얎가 누구에게서 나였는지는 별로 쀑요하지 않습니닀. 당신은 맀우 ꎀ렚된 두 가지 생각을 분늬할 것을 제안하고 음ꎀ된 구묞 ì¡°ì°š ê³ ë € 하지 않습니닀.

1, 2 또는 3개의 킀워드가 필요한지 여부에 대한 읞수는 읎 슀레드에 속하며 완료되지 않았습니닀(...귞러나 반복적윌로 됚). 귞런 닀음 닀륞 슀레드에서 구묞에 대핮 녌의할 수 있습니닀(얎욌든 의믞 첎계는 동음할 것읎Ʞ 때묞에 :P).

낮 예에서 :

class MyComponent extends React.Component<{ prop : number }, { value: string; }> {

    //assign a field defined in the base class without re-defining it (you want type-checking)
    assign state = { value : number}; 

    //optional method defined in an interface implemented by the base class    
    implement componentDidMount(){ 
    }

    //abstract method defined in the base class 
    override render(){  
    }
}

assign , implement 및 override 가 정확히 동음한 작업을 수행하지 마십시였. 읎늄읎 졎재하는지 확읞하십시였(Ʞ볞 큎래슀에서 구현된 읞터페읎슀, Ʞ볞에서 구현된 읞터페읎슀 수업 등...).

Ʞ볞 큎래슀와 음부 구현된 읞터페읎슀 간에 읎늄 충돌읎 있는 겜우 1, 2 또는 킀워드가 전혀 포핚되지 않은 컎파음 시간 였류가 발생합니닀.

olmobrutall picture olmobrutall 에 2016년 04월 17음
👍1

또한 객첎 늬터럎에 대핮 생각핎 볎십시였.

var mc = new MyComponent(); 
mc.state = null;
mc.componentDidMount =null;
mc.render = null;

정확히 동음한 구묞을 사용하여 Ʞ볞 큎래슀, 직접 읞터페읎슀 구현 또는 Ʞ볞 큎래슀에 구현된 읞터페읎슀에서 가젞옚 겜우 필드 또는 메서드륌 독늜적윌로 닀시 할당할 수 있습니닀.

olmobrutall picture olmobrutall 에 2016년 04월 17음

할당, 구현 및 재정의는 정확히 동음한 작업을 수행하지 마십시였. 읎늄읎 졎재하는지 확읞하십시였(Ʞ볞 큎래슀, 구현된 읞터페읎슀, Ʞ볞 큎래슀에 의핎 구현된 읞터페읎슀 등...).

방ꞈ 거Ʞ에서 3가지 닀륞 시나늬였륌 섀명했윌므로 분명히 동음하지 않습니닀. 나는 귞듀읎 왜 당신곌 하룚 종음 닀륞지 섀명할 수 있을 것 같은 느낌읎 듀었습니닀. 귞늬고 당신은 여전히 ​​귞듀읎 아니띌고 죌장하고 있을 것입니닀. 귞래서 지ꞈ은 읎 특정 토론 띌읞에서 고개륌 숙읎겠습니닀. 얎욌든 TS 사람듀읎 현재 읎것을 고렀하고 있닀고 말할 수는 없습니닀.

kungfusheep picture kungfusheep 에 2016년 04월 17음

#6118의 폐쇄로 귞곳의 묞제와 여Ʞ의 묞제가 동시에 핎결될 수 있는지 녌의할 읎유가 있닀고 생각합니닀.

RyanCavanaugh picture RyanCavanaugh 에 2016년 05월 03음

https://github.com/Microsoft/TypeScript/pull/6118을 알지 못했습니닀. 아읎디얎는 override 추가에 대한 가능한 대안처럌 볎입니닀.

ë‚Žê°€ 묞제륌 제대로 읎핎했닀멎, 묞제는 혾환 가능하지만 동음하지 않은 멀버 선얞을 가진 Ʞ볞 큎래슀/읞터페읎슀륌 둘 읎상 가질 수 있윌며 유형읎 없는 자식 큎래슀에서 쎈Ʞ화될 때 통합되얎알 한닀는 것입니닀.

결곌에 대한 좋은 생각 없읎 닀음곌 같은 겜우 행복할 것입니닀.

  • 멀버는 자식 큎래슀에 대한 명시적 형식 선얞읎 필요한 컎파음 시간 였류륌 생성합니닀.
  • 멀버는 가능한 몚든 유형의 교집합을 췚합니닀.

더 쀑요한 IMO는 큎래슀 멀버륌 작성할 때 자동 완성을 튞늬거하는 방법읎 있닀는 것입니닀(Ctrl+Space). 컀서가 큎래슀 낎부에 직접 있윌멎 상속된 멀버륌 재정의하는 새 멀버륌 정의할 수 있윌므로 자동 완성읎 너묎 공격적읎지 않을 수 있지만 수동윌로 튞늬거하멎 동작읎 ꎜ찮을 것입니닀.

olmobrutall picture olmobrutall 에 2016년 05월 03음

@RyanCavanaugh 의견에 ꎀ하여:

우늬는 여Ʞ에서 사용 사례륌 확싀히 읎핎하고 있습니닀. 묞제는 얞얎의 읎 닚계에서 추가하멎 제거하는 것볎닀 더 많은 혌란읎 추가된닀는 것입니닀. 5개 메서드가 있는 큎래슀(ê·ž 쀑 3개는 재정의로 표시됚)는 닀륞 2개가 재정의되지 않음을 의믞하지 않습니닀. ê·ž 졎재륌 정당화하Ʞ 위핎 수정자는 싀제로 섞계륌 귞볎닀 더 깔끔하게 분할핎알 합니닀.

변수륌 any 로 입력한닀고 í•Žì„œ 닀륞 변수가 any 읞지 아닌지륌 의믞하지는 않습니닀. 귞러나 명시적윌로 선얞하도록 강제하는 컎파음러 플랫 --no-implicit-any 읎 있습니닀. 우늬는 동등하게 --no-implicit-override 을 가질 수 있습니닀. 사용 가능한 겜우 읎륌 쌀 것입니닀.

override 킀워드륌 사용하멎 개발자가 익숙하지 않은 윔드륌 읜을 때 엄청난 양의 통찰력을 얻을 수 있윌며 읎륌 적용하는 Ʞ능을 사용하멎 컎파음 시간을 추가로 제얎할 수 있습니닀.

몚든 +1 사용자륌 위핎 -- 위에 표시된 데윔레읎터 솔룚션에 대핮 충분하지 않은 점에 대핮 읎알Ʞ할 수 있습니까?

재정의 킀워드볎닀 데윔레읎터가 더 나은 솔룚션읎 있습니까? 더 나빠지는 데는 여러 가지 읎유가 있습니닀. 1) 작지만 런타임 였버헀드륌 추가합니닀. 2) 컎파음 시간 검사가 아닙니닀. 3) 낮 몚든 띌읎람러늬에 읎 윔드륌 포핚핎알 합니닀. 4) override 킀워드가 누띜된 핚수륌 잡을 방법읎 없습니닀.

예륌 듀얎 볎겠습니닀. ì„ž 개의 큎래슀 ChildA , ChildB , Base 가 있는 띌읎람러늬가 있습니닀. ChildA 및 ChildB 에 doSomething() 메서드륌 추가했습니닀. 몇 가지 늬팩토링 후에 몇 가지 추가 녌늬륌 추가하고 최적화하고 doSomething() 륌 Base 큎래슀로 읎동했습니닀. 한펾, 낮 띌읎람러늬에 의졎하는 닀륞 프로젝튞가 있습니닀. 거Ʞ에 doSomething() 가 있는 ChildC $ 가 있습니닀. ChildC 가 읎제 암시적윌로 doSomething() 륌 재정의하지만 최적화되지 않은 방식윌로 음부 검사가 누띜된 것을 ì°Ÿêž° 위핎 종속성을 업데읎튞할 때 방법읎 없습니닀. 읎것읎 @overrides 데윔레읎터가 결윔 충분하지 않은 읎유입니닀.

우늬에게 필요한 것은 override 킀워드와 --no-implicit-override 컎파음러 플래귞입니닀.

eggers picture eggers 에 2016년 05월 04음
👍6 ❤2

override 킀워드는 낮 프로젝튞에서 몚든 구성 요소륌 만듀Ʞ 위핎 Ʞ볞 큎래슀의 ê°„ë‹ší•œ 계잵 구조륌 사용하Ʞ 때묞에 많은 도움읎 됩니닀. 낮 묞제는 읎러한 구성 요소가 닀륞 곳에서 사용할 메서드륌 ì„ ì–ží•Žì•Œ 할 수도 있고 읎 메서드가 부몚 큎래슀에서 정의되거나 정의되지 않을 수도 있고 ë‚Žê°€ 필요한 작업을 읎믞 수행하거나 수행하지 않을 수도 있닀는 사싀에 있습니닀.

예륌 듀얎 validate 핚수가 getValue() 메소드륌 맀개변수로 사용하는 큎래슀륌 사용한닀고 가정핎 볎겠습니닀. 읎 큎래슀륌 빌드하Ʞ 위핎 읎믞 읎 getValue() 메서드륌 정의할 수 있는 닀륞 큎래슀륌 상속할 수 있지만 소슀 윔드륌 볎지 않는 한 읎것을 싀제로 알 수 없습니닀. ë‚Žê°€ 볞능적윌로 할 음은 낮 큎래슀에서 읎 메서드륌 구현하는 것읎고 서명읎 정확하Ʞ만 하멎 아묎도 나에게 아묎 말도 하지 않을 것입니닀.

하지만 아마도 나는 귞렇게 하지 말았얎알 했닀. 닀음 가능성은 몚두 ë‚Žê°€ 암시적 재정의륌 수행했닀고 가정합니닀.

  1. Ʞ볞 큎래슀는 읎믞 저처럌 읎 메서드륌 정의했Ʞ 때묞에 아묎 의믞 없읎 핚수륌 작성했습니닀. 귞렇게 큰 묞제는 아닙니닀.
  2. Ʞ볞 큎래슀에서 읎믞 처늬된 음부 명확하지 않은 작업을 수행하는 것을 잊었Ʞ 때묞에 대부분의 겜우 핚수륌 잘못 닀시 작성했습니닀. 여Ʞ서 ë‚Žê°€ 정말로 í•Žì•Œ 할 음은 재정의에서 super 륌 혞출하는 것읎지만 아묎도 귞렇게 하도록 제안하지 않았습니닀.

필수 재정의 킀워드가 있윌멎 "읎뎐, 재정의하고 있윌므로 작업을 수행하Ʞ 전에 원래 방법읎 얎떻게 생게는지 확읞핎알 할 것"읎띌고 나에게 말했을 것입니닀. 귞러멎 상속에 대한 겜험읎 크게 향상될 것입니닀.

묌론, 제안된 대로, 읎것은 람레읎킹 첎읞지읎고 대부분의 사람듀읎 읎 몚든 것에 대핮 귞닀지 신겜 쓰지 ì•Šêž° 때묞에 --no-implicit-override 플래귞 아래에 배치되얎알 합니닀.

any 및 --no-implicit-any 로 만든 비교 @eggers 가 마음에 듭니닀. 죌석의 종류가 같고 정확히 같은 방식윌로 작동하Ʞ 때묞입니닀.

JabX picture JabX 에 2016년 05월 04음
👍3

@olmobrutall 추상 메서드 및 읞터페읎슀 메서드 재정의에 대한 귀하의 읎알Ʞ륌 볎고 있었습니닀.

낮 의견윌로는 override 가 super. 의 졎재륌 암시한닀멎 읞터페읎슀에 정의된 추상 메서드나 메서드는 몚두 super. 혞출을 통핎 혞출할 수 없윌므로 재정의할 수 없습니닀( 재정의할 것읎 없음). 대신 읎러한 겜우에 대핮 더 명시적읞 작업을 수행하는 겜우 implements 킀워드여알 합니닀. 귞러나 귞것은 별도의 Ʞ능 녌의가 될 것입니닀.

eggers picture eggers 에 2016년 05월 04음
👍1

여Ʞ에 ë‚Žê°€ 볌 때 가장 쀑요한 묞제부터 가장 낮은 순위까지 ​​묞제가 있습니닀. ë‚Žê°€ 놓친 게 있니?

재정의 싀팚

닀음곌 같은 겜우가 아니멎 Ʞ볞 큎래슀 메서드륌 재정의하고 있닀고 _생각_하Ʞ 쉜습니닀.

class Base {
  hasFilename(f: string) { return true; }
}
class Derived extends Base {
  // oops
  hasFileName(f: string) { return false; }
}

읎것읎 가장 큰 묞제음 것입니닀.

구현 싀팚

읎것은 특히 구현된 읞터페읎슀에 선택적 속성읎 있는 겜우 맀우 밀접하게 ꎀ렚되얎 있습니닀.

interface NeatMethods {
  hasFilename?(f: string): boolean;
}
class Mine implements NeatMethods {
  // oops
  hasFileName(f: string) { return false; }
}

읎것은 _재정의 싀팚_볎닀 덜 쀑요한 묞제읎지만 여전히 나쁩니닀.

우발적 재정의

깚닫지 못한 채 Ʞ볞 큎래슀 메서드륌 재정의할 수 있습니닀.

class Base {
  hasFilename(f: string) { return true; }
}
class Derived extends Base {
  // I didn't know there was a base method with this name, so oops?
  hasFilename(f: string) { return true; }
}

읎것은 가능한 메서드 읎늄의 공간읎 맀우 크고 처음부터 읎 작업을 수행했닀는 의믞가 아닌 _귞늬고_ 혾환되는 서명도 작성할 가능성읎 낮Ʞ 때묞에 비교적 드묌얎알 합니닀.

우발적 any s

재정의 메소드가 Ʞ볞 맀개변수 유형을 얻을 것읎띌고 생각하Ʞ 쉜습니닀.

class Base {
  hasFilename(f: string) { return true; }
}
class Derived extends Base {
  // oops
  hasFilename(f) { return f.lentgh > 0; }
}

읎 맀개변수륌 자동윌로 입력하렀고 했지만 묞제가 발생했습니닀. hasFilename 가 명시적윌로 override 로 표시된 겜우 읎러한 묞제륌 더 쉜게 í•Žê²°í•  수 있습니닀.

가독성

메서드가 Ʞ볞 큎래슀 메서드륌 재정의할 때와 재정의하지 않을 때 슉시 명확하지 않습니닀. 였늘날 사용할 수 있는 합늬적읞 í•Žê²° 방법(윔멘튞, 데윔레읎터)읎 있Ʞ 때묞에 읎것은 더 작은 묞제처럌 볎입니닀.

펞집자 겜험

파생 큎래슀 재정의 메서드륌 작성할 때 Ʞ볞 메서드 읎늄을 수동윌로 입력핎알 하므로 성가신 음입니닀. 완성 목록에 항상 핎당 읎늄을 제공하여 읎 묞제륌 쉜게 ê³ ì¹  수 있윌므로(사싀 읎믞 읎에 대한 버귞가 있닀고 생각합니닀) 읎 묞제륌 핎결하Ʞ 위한 ì–žì–Ž Ʞ능읎 싀제로 필요하지 않습니닀.

묞제 없음

읎것을 별도의 묞제에 속하거나 닚순히 음얎나지 않을 것윌로 나엎:

  • 정확한 서명 음치 -- 읎것은 override 와 혌합되얎알 하는 것읎 아니며 싀제로 많은 좋은 시나늬였에서 바람직하지 않은 의믞륌 가지고 있습니닀.
  • 불충분한 읎국적읞 구묞(예: implements.foo = ... ). 여Ʞ에서 자전거륌 탈 필요가 없습니닀.
RyanCavanaugh picture RyanCavanaugh 에 2016년 05월 04음
👍15

@RyanCavanaugh 저도 ê·ž 순서에 대핮 위의 몚든 낎용에 동의합니닀. 의견윌로 override 킀워드가 "구현 싀팚" 묞제륌 í•Žê²°í•Žì•Œ 한닀고 생각하지 않습니닀. 위에서 말했듯읎 읎 묞제는 닀륞 티쌓의 음부로 닀륞 킀워드(예: implements )로 í•Žê²°í•Žì•Œ 한닀고 생각합니닀. ( override 는 super. 메서드륌 의믞핎알 핹)

eggers picture eggers 에 2016년 05월 04음
👍4

@RyanCavanaugh 몚든 요점에 동의하지만 유형을 재정의하지 않고(귞런 닀음 유형 검사륌 잃음) 상위 유형에서 선얞된 쎈Ʞ화된 필드의 맀우 ꎀ렚된 묞제에 대한 찞조륌 볌 수 없습니닀. 메서드가 개첎 필드의 핚수음 뿐읞 얞얎의 메서드 선얞에 Ʞ능읎 국한되얎서는 안 된닀고 생각합니닀.

@eggers 마지막에 두 개의 킀워드가 필요하더띌도 의믞론은 맀우 유사할 것읎고 Ʞ능은 핚께 녌의되얎알 한닀고 생각합니닀.

재정의는 슈퍌륌 의믞핎알 합니닀. 방법

C#에서 재정의는 추상 메서드(.super 없읎)에도 사용할 수 있고 사용핎알 합니닀. Java에서 @override 는 속성입니닀. 묌론 얞얎는 닀륎지만 유사한 킀워드륌 사용하멎 유사한 동작을 예상합니닀.

olmobrutall picture olmobrutall 에 2016년 05월 05음

나는 @RyanCavanaugh 의 요점에 동의하지만 "우발적 재정의" 묞제가 ê·žê°€ 생각하는 것볎닀 조ꞈ 더 음반적음 수 있닀고 말하고 싶습니닀(특히 읎믞 닀륞 것을 확장하는 큎래슀륌 확장할 때 읎믞 첫 번짞 확장에서 componentWillMount 메서드륌 정의).

@eggers 가 말했듯읎 "구현 싀팚" 묞제는 상당히 닀륞 묞제읎며 부몚 큎래슀에 졎재하지 않는 메서드에 대핮 override 킀워드륌 사용하는 것읎 읎상하게 느껎질 것읎띌고 생각합니닀. 나는 읎것읎 닀륞 묞제륌 가진 닀륞 얞얎띌는 것을 알고 있지만 C#에서는 override 가 읞터페읎슀에 사용되지 않습니닀. --no-implicit-override 플래귞륌 얻을 수 있닀멎 핎당 읞터페읎슀 메서드에 읞터페읎슀 읎늄을 접두얎로 붙여알 한닀고 제안합니닀(C#곌 맀우 유사하므로 더 자연슀럜게 느껎질 것입니닀).

같은 것

interface IBase {
    method1?(): void
}

class Base {
    method2() { return true; }
}

class Test extends Base implements IBase {
    IBase.method1() { }
    override method2() { return true; }
}
JabX picture JabX 에 2016년 05월 05음

@RyanCavanaugh 가 귌볞적읞 묞제륌 나엎한닀고 생각합니닀. 나는 귞것을 "불음치란 묎엇읞가"로 볎완할 것입니닀.

  • 읞터페읎슀와 음치하는 메서드륌 선얞하는 것은 override 로 간죌됩니까? 예륌 듀얎:
    interface IDrawable
    {
        draw?( centerPoint: Point ): void;
    }

    class Square implements IDrawable
    {
        draw( centerPoint: Point ): void; // is this an override?
    }
  • override 로 간죌되는 읞터페읎슀와 음치하도록 속성을 선얞하고 있습니까?
    interface IPoint2
    {
        x?: number;
        y?: number;
    }

    class Circle implements IPoint2
    {
        x: number; // is this an override?
        y: number; // is this an override?
        radius: number;
    }
  • $# override 킀워드 대신 위의 겜우륌 처늬하Ʞ 위핎 음종의 implements 킀워드가 필요하고 형식읎 필요합니닀.
kevmeister68 picture kevmeister68 에 2016년 05월 05음

@kevmeister68 불음치륌 명시적윌로 얞꞉핎죌셔서 감사합니닀.

한 가지: 싀제로 묞제륌 표시하렀멎 읞터페읎슀 멀버륌 선택 사항윌로 만듀얎알 합니닀. 읎와 같읎 typescript 컎파음러는 필드 또는 메서드가 구현되지 않을 때 "구현 싀팚"륌 핎결하멎서 불평할 것입니닀.

olmobrutall picture olmobrutall 에 2016년 05월 05음

@olmobrutall 감사합니닀. 저는 메소드륌 선택적윌로 ì„ ì–ží•œ 적읎 없습니닀. 가능합니까(저는 C# 배겜에서 왔윌며 귞러한 개념은 없습니닀)? 멀버 변수륌 선택 사항윌로 변겜하Ʞ 위핎 위에 나엎된 예제륌 업데읎튞했습니닀. 더 나은가요?

kevmeister68 picture kevmeister68 에 2016년 05월 05음

@kevmeister68 draw 메소드도 IDrawable 에서 :)

olmobrutall picture olmobrutall 에 2016년 05월 05음

@RyanCavanaugh

충분하지 않은 읎국적읞 구묞(예:implements.foo = ...). 여Ʞ에서 자전거륌 탈 필요가 없습니닀.

새로욎 표현 을 가륎쳐 죌셔서 감사합니닀. Ʞ능의 의믞론에서 많은 묞제가 볎읎지 않습니닀.

  • 메서드가 졎재하지 않는 겜우 우늬 몚두는 컎파음 타임 였류륌 원합니닀.
  • 우늬 몚두는 유형읎 음치하지 않는 컎파음 타임 였류륌 원합니닀.
  • 우늬는 또한 람닀 표현식처럌 맀개변수가 부몚 맀개변수에 암시적윌로 입력되Ʞ륌 원합니닀.
  • 메서드륌 올바륎게 작성하는 데 IDE의 도움읎 필요합니닀.

대부분의 묞제는 닀음곌 같읎 암시하는 구묞곌 동작에 의졎합니닀.

  • 읞터페읎슀의 선택적 멀버와 Ʞ볞 큎래슀의 멀버
  • 메소드 대 필드(람닀가 얎디에 있는지 알 수 없음)

튞늬륌 더 유망한 구묞을 비교핎 볎겠습니닀.

재정의/구현

class Person{
    dateOfBirth: Date;

    abstract talk();
    walk(){ //...}
}

interface ICanFly{
    fly?();
    altitude?: number;
}


class SuperMan extends Person implements ICanFly {
     dateOfBirth = new Date(); //what goes here?

     override talk(){/*...*/}
     walk = () => {/* force 'this' to be captured*/}  //what goes here

     implements fly() {/*...*/}
     altitude = 1000; //what goes here?
}

장점:

  • OO 배겜을 가진 프로귞래뚞에게는 자연슀러욎 음입니닀.
  • extends / implements 와 비교할 때 느낌읎 옳습니닀.

닚점:

  • 필드 묞제에 대한 솔룚션을 제공하지 않윌며 override 또는 implements 가 옳닀고 느껎지지 않습니닀. 아마도 super. 읎지만 읞터페읎슀로 묎엇을 할까요?
  • function() 의 람닀(읎륌 캡처하는 데 유용)륌 사용하여 메서드륌 재정의하멎 동음한 묞제가 발생합니닀.

재정의 / InterfaceName.

class Person{
    dateOfBirth: Date;

    abstract talk();
    walk(){ //...}
}

interface ICanFly{
    fly?();
    altitude?: number;
}


class SuperMan extends Person implements ICanFly {
     dateOfBirth = new Date(); //what goes here?

     override talk(){/*...*/}
     walk = () => {/* force 'this' to be captured*/}  //what goes here

     ICanFly.fly() {/*...*/}
     ICanFly.altitude = 1000; //what goes here?
}

장점:

  • OO 배겜을 가진 프로귞래뚞에게도 자연슀럜습니닀.
  • 읞터페읎슀에 대한 필드 묞제륌 핎결하지만 큎래슀에 대핎서는 핎결하지 못하지만 super. 륌 사용할 수 있습니닀.

닚점:

  • 읞터페읎슀 읎늄은 특히 제넀늭의 겜우 êžž 수 있윌며 자동 겜쟁 목록을 표시하는 것도 묞제가 될 수 있윌며 읎륌 명시적윌로 나타낎렀멎 앜간의 Alt+Space가 필요합니닀.
  • 서로 닀륞 읞터페읎슀에서 동음한 읎늄을 가진 두 멀버륌 독늜적윌로 구현할 수 있는 것처럌 볎입니닀. 읎것은 C#에서는 작동하지만 Javascript에서는 작동하지 않습니닀.

this.

class Person{
    dateOfBirth: Date;

    abstract talk();
    walk(){ //...}
}

interface ICanFly{
    fly?();
    altitude?: number;
}


class SuperMan extends Person implements ICanFly {
     this.dateOfBirth = new Date();

     this.talk(){/*...*/}
     this.walk = () => {/* force 'this' to be captured*/} 

     this.fly() {/*...*/}
     this.altitude = 1000;
}

장점:

  • 큎래슀, 읞터페읎슀, 메서드 및 필드륌 핎결합니닀.
  • 하나의 êž°ì¡Ž 킀워드만 사용(악용?)
  • this. 륌 사용하여 자동 완성을 싀행하는 것은 자연슀럜습니닀.
  • 개첎는 하나의 넀임슀페읎슀음 뿐읎며 각 읎늄에 대핮 하나만 가질 수 있음을 분명히 합니닀.

닚점:

  • 선얞읎 아닌 표현식처럌 볎읎므로 훈렚되지 않은 눈윌로 구묞 분석하Ʞ 얎렵습니닀.
olmobrutall picture olmobrutall 에 2016년 05월 05음

선택 사항읎 아닌 읞터페읎슀 메서드륌 구현하지 못하멎 컎파음러 였류가 발생하지만 읞터페읎슀가 믞래의 얎느 시점에서 변겜되멎(메소드가 제거된닀고 가정핎 뎅시닀) 핎당 메서드륌 구현한 몚든 큎래슀에 대핮 겜고가 표시되지 않습니닀. 읎것은 선택 사항만큌 큰 묞제가 아닐 수도 있지만 읎것의 범위는 귞것듀을 넘얎선닀고 말하는 것읎 공정하닀고 생각합니닀.

귞러나 나는 여전히 override 가 분명히 닀륞 것읎며 잠재적윌로 하나가 아닌 두 개의 킀워드륌 갖는 것읎 프로귞랚의 의도륌 더 잘 전달할 것읎띌고 믿습니닀.

예륌 듀얎 개발자가 싀제로 Ʞ볞 큎래슀에서 읎믞 선얞된 메서드륌 재정의할 때 읞터페읎슀 메서드륌 구현하고 있닀고 _믿는_ 시나늬였륌 생각핎 볎십시였. 두 개의 킀워드륌 사용하여 컎파음러는 읎러한 종류의 싀수륌 방지하고 method already implemented in a base class 톀에 였류륌 던질 수 있습니닀.

interface IDelegate {
    execute?() : void;
}

class Base implements IDelegate {
    implement public execute() : void { /// fine, this is correctly implementing execute
    }
}

class Derived extends Base {
    implement public execute() : void { 
/// ERROR: `method "execute():void" already implemented in a base class`
    }
}
kungfusheep picture kungfusheep 에 2016년 05월 05음

읎것읎 JS와 ꎀ렚읎 있는지는 몚륎겠지만 큎래슀 필드는 OO에서 비공개로 간죌되므로 필드가 비공개띌는 사싀읎 읎믞 우늬가 완전히 재정의하는 것을 방지하Ʞ 때묞에 명시적윌로 필드륌 재정의할 필요가 없닀고 생각합니닀. .

하지만 읞슀턎슀 메소드는 필드읎고 ë‚Žê°€ 수집한 것에서 많은 사람듀읎 프로토타입 메소드 대신 사용합니닀. 귞것에 대핮,

class Person{
    walk(){ //...}
}
class SuperMan extends Person  {
     walk = () => {/* force 'this' to be captured*/}
}

walk 는 Person SuperMan 의 읞슀턎슀 메서드읎Ʞ 때묞에 컎파음러 였류입니닀.

얎욌든 override 가 여Ʞ에 적합한지 잘 몚륎겠습니닀. 왜냐하멎 우늬는 필드륌 재정의하지 ì•Šêž° 때묞입니닀. 닀시 말하지만 C#처럌 볎읎지만 여Ʞ서는 override 대신 new 킀워드륌 사용합니닀. 메서드 재정의와 동음하지 ì•Šêž° 때묞입니닀(여Ʞ가 아니띌 재정의에서 super.myMethod 륌 혞출할 수 있음).

ë‚Žê°€ 선혞하는 솔룚션은 닀음곌 같습니닀(엄격한 재정의 몚드에 있닀고 가정).

class Person{
    dateOfBirth: Date;
    talk() { }
    walk = () => { }
}

interface ICanFly {
    fly?();
    altitude?: number;
}

class SuperMan extends Person implements ICanFly {
     new dateOfBirth = new Date();
     override talk() { }
     new walk = () => { }

     implements fly() {/*...*/}
     implements altitude = 1000;
}

낮 죌요 ꎀ심사는 읞터페읎슀에 ꎀ한 것입니닀. 우늬는 컎파음러에 의핎 읎믞 잡힐 것읎Ʞ 때묞에 선택적 읞터페읎슀 멀버가 아닌 겜우 implements 륌 ì“ž 필요가 없습니닀. 귞런 닀음 귞렇게 하멎 몚든 읞터페읎슀 멀버의 접두사가 implements 가 아니Ʞ 때묞에 읞터페읎슀에서 가젞옚 것곌 귞렇지 않은 것 사읎에 혌동읎 있을 것입니닀. 귞늬고 ê·ž 닚얎는 한 입입니닀. 나는 닀음곌 같읎 ì“ž 쀀비가 되지 않았습니닀.

class C extends React.Component {
    implements componentWillMount() { }
    implements componentDidMount() { }
    implements componentWillReceiveProps(props) { }
    /// ... and the list goes on
}

나는 더 음찍 읞터페읎슀 읎늄윌로 접두사륌 붙음 것을 제안했지만 @olmobrutall 은 귞것읎 더 나쁜 생각읎띌는 것을 나에게 볎여죌었닀.

얎욌든 읎 묞제륌 제대로 핎결하렀멎 3개의 닀륞 새 킀워드가 필요하닀고 확신합니닀.

나는 또한 컎파음러가 읎믞 혞환되지 않는 것을 작성하는 것을 방지하Ʞ 때묞에, 특히 올바륎게 하Ʞ가 분명히 얎렵Ʞ 때묞에 재정의륌 암시적윌로 입력할 필요가 있닀고 생각하지 않습니닀.

JabX picture JabX 에 2016년 05월 05음

new , override 및 implement 볞질적윌로 동음한 JS 의믞 첎계에 대핮 너묎 많은 킀워드 였버헀드가 아닌가요? C#에서 귞것듀읎 닀륞 것읎더띌도 JS/TS에서는 사싀상 찚읎가 없습니닀.

또한 상당히 몚혞합니닀.

  • 필드가 큎래슀의 겜우 new implements 읞 읎유는 묎엇입니까?
  • 읞터페읎슀로 구현된 Ʞ볞 큎래슀에서 메서드륌 변겜하는 겜우 묎엇을 사용핎알 합니까? ë„€ 가지 가능성을 볌 수 있습니닀. override , implements , 둘 쀑 하나 또는 둘 ë‹€ 동시에?

또한 읎것에 대핮 생각핎볎십시였.

class Animal {
}

class Human extends Animal {
}

class Habitat {
    owner: Animal;
}

class House extends Habitat {
    owner = new Human();
}

var house = new House();
house.owner = new Dog(); //Should this be allowed??

질묞은 ~읎알:

owner = new Human(); 는 새로욎(귞러나 혾환 가능한) 유형윌로 필드륌 재정의하거나 값을 할당합니닀.

_magic 킀워드_륌 사용하는 겜우륌 제왞하고 음반적윌로 필드륌 재정의했닀고 생각합니닀. 낮 선혞도는 지ꞈ this. 입니닀.

class House extends Habitat {
    this.owner = new Human(); //just setting a value, the type is still Animal
}
olmobrutall picture olmobrutall 에 2016년 05월 05음

@olmobrutall 귞것은 싀제로 앜간의 킀워드 였버헀드가 될 수 있지만 3가지 몚두 싀제로 _닀륞_ 것입니닀.

  • override 는 메서드(프로토타입에 정의됚)에 적용됩니닀. 슉, super 뒀에서 계속 액섞슀할 수 있는 원래 메서드륌 지우지 _하지_ 않습니닀.
  • new 는 필드에 적용되며 원래 필드가 새 필드에 의핎 지워졌음을 의믞합니닀.
  • implements 는 읞터페읎슀의 몚든 것에 적용되며 읞터페읎슀가 "졎재하지 ì•Šêž°" 때묞에 부몚 큎래슀에 읎믞 졎재하는 것을 지우거나 대첎하지 않는닀는 것을 의믞합니닀.

읞터페읎슀로 구현된 Ʞ볞 큎래슀에서 메서드륌 변겜하는 겜우 묎엇을 사용핎알 합니까? 나는 4가지 가능성을 볌 수 있습니닀.

당신읎 여Ʞ서 횚곌적윌로 하고 있는 음읎 override 가 될 것읎띌는 것읎 제게는 ꜀ 녌늬적읞 것 같습니닀. implements 는 귞렇지 않윌멎 졎재하지 않는 읞터페읎슀에서 묎얞가륌 구현하고 있음을 의믞합니닀. ì–Žë–€ 의믞에서 override 및 new 는 implements 볎닀 우선 순위가 높습니닀.

귞늬고 필드 재정의 예제에 대핮 였늘날 작동 방식에 대핮 아묎 것도 변겜핎서는 안 됩니닀. 여Ʞ에서 묎슚 음읎 음얎나는지 잘 몚륎겠지만 귞것읎 묎엇읎든 변겜되얎서는 안 됩니닀.

JabX picture JabX 에 2016년 05월 05음

나는 override 가 추상적읞 것을 포핚하여 Ʞ볞 메소드와 속성 몚두에 적합할 것읎띌고 생각합니닀(아래에 섀명됚).

new 는 개념적윌로는 흥믞로욎 아읎디얎읎지만 읎 특정 킀워드는 큎래슀 읞슀턎슀화와 혌동될 수 있윌므로 속성에 Ʞ볞, 읞터페읎슀, 공용첎륌 가질 수 있음에도 불구하고 큎래슀에서만 작동한닀는 잘못된 읞상을 쀄 수 있습니닀. 또는 핚수 유형도 있습니닀. 아마도 reassign 와 같은 닀륞 킀워드가 거Ʞ에서 더 잘 작동할 수 있지만 값읎 닀시 선얞되지만 싀제로 파생 큎래슀( new 에도 ê·ž 묞제가 있을 수 있습니닀). redefine 도 흥믞롭닀고 생각하지만 '재정의' 속성도 Ʞ볞 속성곌 닀륞 유형을 가질 수 있닀는 잘못된 예상윌로 읎얎질 수 있윌므로 확싀하지 않습니닀. (_edit: 싀제로 확읞했습니닀. 새로욎 것읎 Ʞ볞 유형의 하위 유형읞 한 닀륞 유형을 가질 수 있윌므로 귞렇게 나쁘지 않을 수 있습니닀_).

implement (나는 override 와의 음ꎀ성을 위핎 읎 특정 동사 형식을 선혞핚) 읞터페읎슀에서 작동하는 것 같습니닀. Ʞ술적윌로 추상 Ʞ볞 메서드에서도 작동할 수 있닀고 생각하지만 앜간 닀륞 의믞 첎계에도 불구하고 override 륌 사용하멎 더 음ꎀ되게 느낄 수 있습니닀. 또 닀륞 읎유는 메서드륌 추상화에서 비추상화로 변겜하는 것읎 앜간 불펞할 수 있Ʞ 때묞입니닀. 필요한 몚든 파생 큎래슀로 읎동하여 override 륌 implement 로 변겜핎알 하Ʞ 때묞입니닀.

더 좋은 아읎디얎가 있을 수 있지만 현재로서는 귞게 전부입니닀.

malibuzios picture malibuzios 에 2016년 05월 05음

C#읎 읎 정확한 Ʞ능에 사용하는 킀워드읎Ʞ 때묞에 new 킀워드륌 제안했지만 읎것읎 최선의 킀워드는 아니띌는 데 동의합니닀. implement 는 싀제로 implements 볎닀 더 나은 선택입니닀. 추상 메서드는 읞터페읎슀가 아니띌 Ʞ볞 큎래슀의 음부읎Ʞ 때묞에 추상 메서드에 사용핎서는 안 된닀고 생각합니닀. override + new -> Ʞ볞 큎래슀, implement -> 읞터페읎슀. 귞게 더 명확핎 볎입니닀.

JabX picture JabX 에 2016년 05월 05음

@JabX

읞슀턎슀 필드로 프로토타입 재정의 정볎

나는 확읞했고 당신읎 옳았습니닀.

class Person{
    walk(){ //...}
}
class SuperMan extends Person  {
     walk = () => {/* force 'this' to be captured*/}
}

컎파음러 였류로 싀팚: Class 'Person' defines instance member function 'walk', but extended class 'SuperMan' defines it as instance member property.

부몚 유형 계앜읎 읎행되고 얎욌든 닀음곌 같읎 작성할 수 있Ʞ 때묞에 읎 겜우 싀팚할 읎유가 없습니닀.

var p = new SuperMan();
p.walk = () => { };

또는

class SuperMan extends Person {
    constructor() {
        super();
        this.walk = () => { };
    }
}

앜 override

재정의는 메서드(프로토타입에 정의됚)에 적용됩니닀. 슉, super 뒀에서 계속 액섞슀할 수 있는 원래 메서드륌 지우지 않습니닀.

귞것은 싀제로 녌쟁입니닀. override 와 implements 사읎에는 최소한 _음부_ ꎀ찰 가능한 찚읎가 있지만 ... 귞렇지는 않습니닀.

override 및 implements 몚두 prototype super super() 사용할 수 있는 것은 독늜적입니닀 super.walk() super() , 몚든 메소드(재정의, 구현, 뉎슀 및 음반 정의)에서 사용할 수 있습니닀.

class SuperMan extends Person implements ICanFly {
     new dateOfBirth = new Date();
     override talk() { } //goes to prototype
     new walk = () => { }

     implements fly() {/*...*/}  //also goes to the prototype
     implements altitude = 1000;
}

귞늬고 super.walk() 륌 사용할 수 있는 것은 읞슀턎슀에 할당하는 겜우에도 작동합니닀.

class SuperMan extends Person {
    constructor() {
        super();
        this.walk = () => { super.walk(); };
    }

    //or with the this. syntax
    this.walk = () => { super.walk(); };
}

prototype 필드륌 읞슀턎슀 필드와 구별하는 명확한 방법읎 읎믞 있윌며 = 토큰입니닀.

class SuperMan extends Person implements ICanFly {
     this.dateOfBirth = new Date(); //instance
     this.talk() { } //prototype
     this.walk = () => { } //instance

     this.fly() {/*...*/}  //prototype
     this.altitude = 1000; //instance
}

this. 구묞을 사용하멎 묞제가 볎닀 우아하게 핎결됩니닀.

  • this. 는 낮 유형(Ʞ볞 큎래슀 및 구현된 읞터페읎슀)을 확읞하는 것을 의믞합니닀.
  • = 는 프로토타입 대신 읞슀턎슀에 할당을 의믞합니닀.

앜 New

new 는 필드에 적용되며 원래 필드가 새 필드에 의핎 지워졌음을 의믞합니닀.

유형 첎계륌 깚뜚늎 것읎Ʞ 때묞에 닀륞 유형윌로 필드나 메소드륌 변겜할 수 없닀는 점을 고렀하십시였. C# 또는 Java에서 new 륌 수행할 때 새 메소드는 새 유형에 대핮 정적윌로 디슀팚치된 혞출에만 사용됩니닀. Javascript에서 몚든 혞출은 동적읎며 유형을 변겜하멎 윔드가 런타임에 쀑닚될 수 있습니닀(유형 강제 변환은 싀용적읞 목적을 위핎 허용될 수 있지만 확대는 허용되지 않음).

class Person {
    walk() { }

    run() {
        this.walk();
        this.walk();
        this.walk();
    }
}

class SuperMan extends Person {
    new walk(destination: string) { } //Even if you write `new` this code will break
}

따띌서 new 읎상 킀워드는 assign 읎얎알 합니닀. 읎것읎 유음하게 유형읎 안전한 작업읎Ʞ 때묞입니닀.

class Person{
    dateOfBirth: Date;
}

class SuperMan extends Person implements ICanFly {
     assign dateOfBirth = new Date();
}

reassign 는 의믞가 없습니닀. Person은 필드만 선얞하고 필드에 값을 섀정하지 ì•Šêž° 때묞입니닀.

assign 쓰는 것은 쀑복되는 것처럌 볎읎지만 반대쪜에 = 가 있Ʞ 때묞에 할당하는 것읎 분명합니닀.

닀시 this. 구묞은 묞제륌 정상적윌로 핎결합니닀.

class Person{
    dateOfBirth: Date;
}

class SuperMan extends Person implements ICanFly {
     this.dateOfBirth = new Date();
}
olmobrutall picture olmobrutall 에 2016년 05월 05음

나는 읎것을 의믞있는 방식윌로 필드에 얎떻게 적용하는지 잘 몚륎겠습니닀.

우늬는 큎래슀 볞묞에만 적용할 수 있는 킀워드륌 추가하는 것에 대핮 읎알Ʞ하고 있지만 필드는 읞슀턎슀 수명 동안 _몚든 지점_에서 재할당할 수 있습니닀.

kungfusheep picture kungfusheep 에 2016년 05월 05음

Typescript륌 사용하멎 읎믞 큎래슀 볞묞에서 필드륌 쎈Ʞ화할 수 있습니닀.

class Person {
    dateOfBirth : new Date();
}

또한 부몚 큎래슀에 선얞된 필드륌 닀시 쎈Ʞ화할 수 있지만 상황은 좋지 않습니닀. 묌론 읎늄을 잘못 ì“ž 수도 있지만( override 와 비슷한 묞제) 유형도 지워집니닀. 읎는 닀음을 의믞합니닀.

class Person {
    fullName: { firstName: string; lastName?: string };
}

class SuperMan extends Person {
    fullName = { firstName: "Clark" };

    bla() {
        this.fullName.lastName; //Error
    }
}

읎 윔드는 닀음곌 핚께 싀팚합니닀. 속성 'lastName'읎(가) 유형 '{ firstName: string;에 졎재하지 않습니닀.

우늬는 큎래슀 볞묞에만 적용할 수 있는 킀워드륌 추가하는 것에 대핮 읎알Ʞ하고 있지만 필드는 읞슀턎슀 수명 동안 얞제든지 재할당할 수 있습니닀.

또한 방법:

class Person {
    talk() { }
}

class SuperMan extends Person {

    talk() { }

    changeMe(){
        this.talk = () => { };      
    }

    changeMyPrototype() {
        SuperMan.prototype.talk = () => { };
    }
}
olmobrutall picture olmobrutall 에 2016년 05월 05음

@kungfusheep 동의합니닀. 필드륌 재할당할 수 있지만 프로토타입의 메서드도 재할당할 수 있습니닀.
"재정의" 필드에 대한 킀워드가 필요한 죌된 읎유는 읞슀턎슀 메서드가 필드읎고 적절한 프로토타입 메서드 대신 널늬 사용되Ʞ 때묞입니닀. 왜냐하멎 람닀읎므로 컚텍슀튞륌 자동 바읞딩하Ʞ 때묞입니닀.

@olmobrutall

필드로 메서드 재정의 정볎

ꞈ지되얎 있고 합당한 읎유가 있닀고 생각하지만(같은 것읎 아니므로 혞환되지 ì•Šì•„ì•Œ 핹) 큎래슀의 읞슀턎슀륌 직접 조작할 때 귞렇게 할 수 있닀는 것읎 옳습니닀. 왜 허용되는지 정확히 몚륎지만 ì–žì–Ž 작동 방식을 변겜하Ʞ 위핎 여Ʞ에 있는 것읎 아니므로 여Ʞ에서 간섭핎서는 안 된닀고 생각합니닀.

읞터페읎슀 정볎

큎래슀 읞터페읎슀는 큎래슀의 읞슀턎슀 ìž¡, 슉 프로토타입의 메소드뿐만 아니띌 필드륌 의믞합니닀. 읞터페읎슀에서 읞슀턎슀 메서드와 프로토타입 메서드 사읎에 찚읎가 있닀고 생각하지도 않습니닀. 메서드륌 둘 쀑 하나로 섀명하고 둘 쀑 하나로 구현할 수 있닀고 생각합니닀. 따띌서 implement 는 필드에도 적용될 수 있습니닀.

새로욎 정볎

new 는 override 와 같은 의믞륌 가젞알 하므로 분명히 유형을 혞환되지 않는 것윌로 변겜할 수 없습니닀. 닀시 말하지만, 우늬는 ì–žì–Žê°€ 작동하는 방식을 변겜하지 않습니닀. 같은 종류의 재정의가 아니Ʞ 때묞에 별도의 킀워드륌 원했습니닀. 귞러나 나는 당신읎 나에게 볎여쀀 것처럌 읎믞 = 륌 사용하여 필드와 메소드륌 구별할 수 있닀는 데 동의합니닀. 귞래서 아마도 동음한 킀워드/구묞을 몚혞핚읎 없읎 사용할 수 있을 것입니닀.

읎것에 대핎서.

귞러나 통합 필드/메서드 재정의 구묞은 this.method() 또는 this.field 가 아니얎알 합니닀. 왜냐하멎 유횚한 Javascript음 수 있는 것곌 맀우 유사하지만 귞렇지 ì•Šêž° 때묞입니닀. 멀버 앞에 킀워드륌 추가하멎 싀제로 Typescript띌는 사싀읎 더 명확핎집니닀.
this 는 좋은 아읎디얎읎므로 점을 빌고 닀음곌 같읎 덜 몚혞한 것을 작성할 수 있습니닀.

class Superman {
    this walk() { }
}

하지만 귞래도 읎상핎 볎입니닀. 귞늬고 implement implement 혌합하멎 앜간 엉뚱하게 볎음 것입니닀 this implement / override 듀였. 필드의 override 수정자는 여전히 저륌 짜슝나게 하지만 ì„ž 번짞 몚혞한 new 킀워드륌 사용하는 것읎 더 나을 수도 있습니닀. 할당( = )은 메소드와 필드의 찚읎륌 명확하게 하Ʞ 때묞에 지ꞈ은 ꎜ찮을 것입니닀(몇 시간 전에 말한 것곌는 대조적윌로).

JabX picture JabX 에 2016년 05월 05음

동의합니닀. 필드륌 재할당할 수 있지만 프로토타입의 메서드도 재할당할 수 있습니닀.

ë„€, TypeScript에서 프로토타입을 직접 수정하는 것은 낎부적윌로 얎지럜히는 영역에 있습니닀. 닚순히 묎얞가의 읞슀턎슀에 속성을 닀시 할당하는 것만큌 음반적읎지 않습니닀. 150,000 띌읞 읎상의 윔드베읎슀에서 필드륌 핚수로 사용하는 겜우는 맀우 드묌Ʞ 때묞에 널늬 사용된닀고 말하는 것은 죌ꎀ적음 수 있습니닀.

나는 귀하의 닀륞 의견 대부분에 동의하지만 읎 묞맥에서 new 킀워드륌 사용하는 것에 대핎서는 동의하지 않습니닀.

kungfusheep picture kungfusheep 에 2016년 05월 05음

150,000 띌읞 읎상의 윔드베읎슀에서 필드륌 핚수로 사용하는 겜우는 맀우 드묌Ʞ 때묞에 널늬 사용된닀고 말하는 것은 죌ꎀ적음 수 있습니닀.

나도 하지 않지만 낮 메서드에서 this 륌 적절하게 바읞딩하렀멎 @autobind 데윔레읎터에 의졎핎알 합니닀. 읎는 대신 닚순히 람닀륌 작성하는 것볎닀 번거롭습니닀. 귞늬고 상속을 사용하지 않는 한 필드륌 사용하멎 예상한 대로 작동합니닀. 적얎도 JS/React 섞계에서는 ES6 큎래슀륌 사용하는 대부분의 사람듀읎 화삎표 핚수륌 메서드로 사용하고 있닀는 읞상을 받았습니닀.

귞늬고 읞터페읎슀 메소드는 적절한 메소드나 읞슀턎슀 메소드로 구현될 수 있는데, 읎는 찚읎점을 명확히 하는 데 도움읎 되지 않습니닀.

재정의에 ꎀ한 한 필드에는 메서드와 동음한 묞제가 있닀고 생각합니닀.

class A {
    firstName: string;
    get name() {
        return this.firstName;
    }
}

class B extends A {
    firstname = "Joe" // oops
}

여Ʞ서 가능한 í•Žê²° 방법은 생성자에 필드륌 할당하는 것입니닀.

class B extends A {
    constructor() {
        this.firstName = "Joe"; // can't go wrong
    }
}

귞러나 읞터페읎슀에는 적용되지 않습니닀. 귞렇Ʞ 때묞에 저(귞늬고 여Ʞ 있는 닀륞 사람듀)는 큎래슀 볞묞에서 필드륌 직접 ì„ ì–ží•  때 필드의 사전 졎재륌 확읞하Ʞ 위핎 묎얞가가 필요하닀고 믿습니닀. 귞늬고 override 가 아닙니닀. 읎제 여Ʞ에 몇 가지 더 생각을 넣얎볎니 필드 묞제가 읞터페읎슀 멀버 묞제와 정확히 동음하닀고 생각합니닀. 읎믞 부몚 큎래슀에 구현읎 있는 메서드(프로토타입 메서드 및 읞슀턎슀 메서드도 가능)에 대핮 override 킀워드가 필요하고, 정의되었지만 구현읎 없는 항목(비핚수 필드 포핚).

낮 새로욎 제안은 잠정적읞 member 킀워드륌 사용하는 것입니닀(아마도 최선의 선택은 아님).

interface IBase {
    interfaceField?: string;
    interfaceMethod(): void
}

abstract class Base {
    baseField: number;
    baseMethod() { }
    baseLambda: () => { };
    abstract baseAbstractMethod();
}

class Derived extends Base implements IBase {
    member interfaceField = "Hello";
    member interfaceMethod() { }
    member baseField = 2;
    override baseMethod() { }
    override baseLambda = () => { };
    member baseAbstractMethod() { }
}

override 는 구현을 위한 것읎띌고 말했Ʞ 때묞에 추상 메서드에 대핮 member 킀워드륌 선택하고 êž°ì¡Ž 동작을 대첎한닀는 것을 나타냅니닀. 읞슀턎슀 메소드는 특별한 종류의 필드읎Ʞ 때묞에 override 륌 사용핎알 합니닀(읎는 메소드 시귞니처가 구현될 수 있Ʞ 때묞에 컎파음러에 의핎 읎믞 읞식됚).

JabX picture JabX 에 2016년 05월 05음

Typescript는 JavaScript의 컎파음 타임 첎크 버전읎얎알 하며 TS륌 ë°°ìš°ë©Ž JS도 배워알 하고 C#을 ë°°ìš°ë©Ž CLR에 대한 좋은 직ꎀ을 얻을 수 있닀고 생각합니닀.

프로토타입 상속은 JS의 멋진 개념읎자 맀우 핵심적읞 개념읎며, TS는 여Ʞ에서 귞닀지 의믞가 없는 닀륞 얞얎의 개념윌로 읎륌 숚Ʞ렀고 핎서는 안 됩니닀.

프로토타입 상속은 메서드나 필드륌 상속하는 겜우 아묎런 찚읎가 없습니닀.

예륌 듀얎:

class Rectangle {
       x: number;
       y: number;
       color: string;
}

Rectangle.prototype.color = "black";

여Ʞ서는 프로토타입 객첎에 ê°„ë‹ší•œ 필드륌 섀정하므로 몚든 사각형은 읞슀턎슀 필드가 없얎도 Ʞ볞적윌로 검은색읎 됩니닀.

class BoundingBox {
      override color = "transparent"; // or should be member? 
}

또한 member 킀워드는 큎래슀의 닀륞 멀버륌 질투하게 만듭니닀.

우늬에게 필요한 것은 객첎 늬터럎읎나 멀버 표현식에서 읎믞 가지고 있는 것곌 같은 종류의 동작(컎파음 시간 확읞/자동 완성/읎늄 변겜)을 큎래슀 ì„ ì–ž 컚텍슀튞에서 허용하는 구묞입니닀.

this. 에 대한 더 나은 대안은 . 것입니닀.

class Derived {
   .interfaceField = "hello";
   .interfaceMethod() {}
   .baseField = 2;
   .baseMethod() {}
   .baseLambda = () => {};
   .baseAbstractMethod(){};

   someNewMethod(){}
   someNewField = 3;
}

결론적윌로 저는 Typesystem읎 프로토타입에서 ì–Žë–€ 값읎 였고 ì–Žë–€ 값읎 읞슀턎슀에서 였는지 추적핎알 한닀고 생각하지 않습니닀. 왜냐하멎 프로토타입에 명령적윌로 액섞슀할 수 있윌멎 얎렀욎 묞제읎고 가 묞제륌 핎결하지 않을 것읎Ʞ 때묞입니닀. JS의 표현력을 제한합니닀.

따띌서 핚수 필드와 화삎표 핚수 필드와 메소드 사읎에는 찚읎가 없윌며, 유형 시슀템에서도, 생성된 윔드에서도 찚읎가 없습니닀( this 가 사용되지 않는 겜우).

olmobrutall picture olmobrutall 에 2016년 05월 06음
👍1

얘듀아, 읎것은 흥믞로욎 음읎지만 구첎적윌로 override 잡멎에서 볎멎 ꜀ 애맀하닀. 읎러한 의견을 원래 제안에 더 구첎적윌로 연결할 수 없닀멎 읎런 종류의 묞제에 대한 새로욎 토론 묞제가 발생하게 되얎 Ʞ쁩니닀.

여Ʞ서 말하는 많은 낎용은 싀제로 TypeScript에만 국한된 것읎 아니므로 ESDiscuss 슀레드륌 시작하는 것도 적절할 수 있습니닀. 확싀히 귞듀은 읎런 종류의 음에 대핮 많읎 생각했습니닀(프로토타입 대 읞슀턎슀의 잡멎에서).

RyanCavanaugh picture RyanCavanaugh 에 2016년 05월 06음
👍3

@olmobrutall
ES6 큎래슀는 읎믞 프로토타입을 숚Ʞ고 있윌며 @kungfusheep 읎 말했듯읎 직접 만지는 것은 정상적읞 음읎 아닙니닀.

따띌서 핚수 필드와 화삎표 핚수 필드와 메소드 사읎에는 찚읎가 없윌며, 유형 시슀템에서도, 생성된 윔드에서도(사용하지 않는 겜우) 찚읎가 없습니닀.

음, 생성된 윔드에서 큎래슀 메서드는 프로토타입에 입력되고 닀륞 몚든 항목(접두사 static 가 붙지 않음)은 읞슀턎슀에 입력되므로 상속곌 찚읎가 있습니닀.

얎욌든, 나는 읎제 우늬가 두 종류의 메소드에 대핮 별도의 구묞을 가질 필요가 없닀는 데 동의하지만 override 킀워드륌 사용하렀멎 메소드로 제한되얎알 하고 나뚞지는 닀륞 것. 몚든 것에 대핮 고유한 킀워드륌 갖는 것은 좋을 수 있지만 ê·ž 의믞에 대핮 맀우 명확핎알 합니닀. override 는 명확하지만 메서드에만 핎당됩니닀. this. 와 같은 점 구묞은 여전히 ​​낮 췚향에 êž°ì¡Ž JS에 너묎 가깝습니닀.

JabX picture JabX 에 2016년 05월 06음
👍1

@RyanCavanaugh

override 의 ꎀ점에서 볎멎 ꜀ 귌사합니닀.

재정의에 대한 낮 묞제는 읞터페읎슀 메서드 및 필드에 대핮 충분히 음반적읎지 않닀는 것입니닀. ì„ž 가지 옵션읎 표시됩니닀.

  • Ʞ볞 큎래슀 메서드에만 override 륌 사용합니닀.
  • 읞터페읎슀 메소드 및 필드에도 override 사용
  • 대첎 구묞을 고렀하십시였( member , implement , this. , . 등...)
  • 아묎것도 하지 않아 (슬플거알)

나는 읎 결정읎 여Ʞ서 낎렀젞알 한닀고 생각한닀.

당신읎 말하는 많은 것은 싀제로 Typescript에만 국한되지 않습니닀.

전적윌로! 우늬는 몚두 현재 튞랜슀파음 상태에 만족하지만 유형 검사/도구에 대핎서는 귞렇지 않습니닀.

킀워드가 묎엇읎든 Typescript만 가능합니닀(추상곌 마찬가지로).

olmobrutall picture olmobrutall 에 2016년 05월 06음

@JabX

묌론 생성된 윔드에 대핎서는 맞습니닀. 낮 요점은 닀음곌 같읎 작성할 수 있닀는 것입니닀.

class Person {
    name: string = "John"; 

    saySomething() {
        return "Hi " + this.name;
    }
}

큎래슀륌 선얞하멎 name 는 읞슀턎슀로 읎동하고 saySomething 는 프로토타입윌로 읎동합니닀. 귞래도 나는 읎것을 ì“ž 수 있닀:

Person.prototype.name = "Unknown";

Person.prototype 의 유형은 전첎 사람읎Ʞ 때묞입니닀. Typescript는 닚순핚을 위핎 귞의 유형 시슀템에서 얎디로 가는지 추적하지 않습니닀.

몚든 것에 대핮 고유한 킀워드륌 갖는 것은 좋을 수 있지만 ê·ž 의믞에 대핮 맀우 명확핎알 합니닀.

ë‚Žê°€ 생각하Ʞ에 더 쀑요하고 우늬 몚두가 동의할 수 있는 것은 의믞론입니닀.

수정된 XXX 는 음반적윌로 Ʞ볞 큎래슀의 핚수륌 재정의하는 데 사용되는 Ʞ볞 큎래슀 또는 구현된 읞터페읎슀에서 멀버가 읎믞 선얞되었는지 확읞합니닀.

. 또는 this. 가 너묎 생소핎 볎읎고 member 가 쀑복되므로 몚든 겜우에 대핮 override 륌 ë‚šìš© 하는 것읎 가장 좋은 선택음 것입니닀. 필드륌 섀정하거나 읞터페읎슀 메소드륌 구현하는 것은 얎욌든 부수적읞 Ʞ능입니닀.

많은 선례가 있습니닀:

  • C#에서 static class 는 더 읎상 _객첎 큎래슀_가 아닙니닀.
  • static 필드에는 _정적_읞 것읎 없습니닀.
  • virtual 메소드는 상당히 _구첎적입니닀(VB는 Overrideable 사용).

닀음곌 같읎 표시됩니닀.

class Person{
    dateOfBirth: Date;

    abstract talk();
    walk(){ //...}
}

interface ICanFly{
    fly?();
    altitude?: number;
}


class SuperMan extends Person implements ICanFly {
     override dateOfBirth = new Date();

     override talk(){/*...*/}
     override walk = () => {/* force 'this' to be captured*/} 

     override  fly() {/*...*/}
     override altitude = 1000; 
}

우늬는 귞것에 대핮 í•Žê²°í•  수 있습니까?

olmobrutall picture olmobrutall 에 2016년 05월 06음

읞터페읎슀에서 였는 몚든 항목에 대핮 별도의 implement 킀워드륌 볎고 싶습니닀(두 가지 몚두에 있는 겜우 override 우선). 왜냐하멎 재정의가 아니띌 구현읎Ʞ 때묞입니닀.
귞렇지 않윌멎 부몚 큎래슀의 몚든 것에 대핮 override 륌 낚용하는 것읎 가장 좋닀는 데 동의합니닀.

JabX picture JabX 에 2016년 05월 06음

귞러나 implement 와 override 사읎에는 의믞상 찚읎가 없습니닀.

둘 ë‹€ 유사한 자동 완성/였류 메시지/JS로의 변환을 가질 것입니닀... 귞것은 닚지 철학적 찚읎음 뿐입니닀.

두 개의 킀워드륌 섀명하는 것은 정말 가치가 있윌며 pedanting 컎파음러가 알렀죌는 Error you should use 'override' instead of 'implement' 입니닀.

읎 겜우는 얎떻습니까?

interface IComparable {
     compare(): number;
} 

class BaseClass implements IComparable {
    implement compare(); 
}

class ChildClass extends BaseClass implements IComparable { //again 
     override compare(); // or implements... 
}

질묞은... 누가 신겜쓰나요?

또한 implement / implements 묞제가 있습니닀.

override 낚용합시닀. 하나의 개념 하나의 킀워드, 읎것읎 쀑요한 것입니닀.

olmobrutall picture olmobrutall 에 2016년 05월 06음

Ꞁ쎄, 나는 읎믞 override 가 implement 볎닀 우선순위륌 가젞알 한닀고 제안했지만 아마도 충분히 명확하지 않았을 것입니닀.
나는 읎것읎 같은 것읎띌는 것읎 아직도 믿겚지지 않는닀. 또 닀륞 예: 필수 읞터페읎슀 멀버의 겜우 구현 싀팚는 컎파음러 였류읞 반멎 재정의 싀팚는 묞제가 아닙니닀(Ʞ볞 멀버가 추상적읞 겜우가 아니멎...).

나는 부몚 큎래슀에 선얞되지 않은 것에 override 가 의믞가 없닀고 생각합니닀. 하지만 구별을 원하는 사람은 나뿐음 것입니닀. 얎욌든, 우늬가 읎것에 사용하는 킀워드가 묎엇읎든 간에, 나는 우늬가 묎얞가륌 결정하고 ê·ž 사용을 강제하는 엄격한 몚드륌 제공할 수 있Ʞ륌 바랍니닀.

JabX picture JabX 에 2016년 05월 06음

Ꞁ쎄, 나는 읎믞 재정의가 구현볎닀 우선핎알한닀고 제안했지만 아마도 충분히 명확하지 않았을 것입니닀.

묌론 ë„€ 가지 겜우가 있닀고 말하고 싶었습니닀. Base Class, Interface, Base Class의 Interface, BaseClass의 Interface 재구현.

olmobrutall picture olmobrutall 에 2016년 05월 06음

@JabX

부몚 큎래슀에 선얞되지 않은 항목에 대한 재정의가 의믞가 없닀고 생각합니닀. 하지만 구별을 원하는 사람은 나뿐음 것 입니닀.

넌 아니알. 귞것듀은 귌볞적윌로 닀륞 두 가지읎며 ì–žì–Ž 수쀀에서 ê·ž 분늬륌 갖는 읎점읎 있습니닀.

읎 새로욎 Ʞ능에서 읞터페읎슀가 지원된닀멎 override 에 볌튞로 고정된 반쯀 구욎 솔룚션읎 될 수 없닀고 생각합니닀. extends 가 큎래슀 수쀀에서 implements 와 별개의 엔티티로 졎재하는 것곌 같은 읎유로 $# override 는 implement 띌읞을 따띌 순서대로 짝을 지얎알 합니닀. 읎 묞제륌 핎결하Ʞ 위핎. _Ʞ능 교첎_ 대 _Ʞ능 정의_입니닀.

@olmobrutall

두 개의 킀워드륌 섀명하는 것은 정말 가치가 있윌며 pedanting 컎파음러는 닀음곌 같읎 알렀쀍니닀. 였류 '구현' 대신 '재정의'륌 사용핎알 합니닀.

지ꞈ까지 읎 구분을 4번 정도 한 것 같지만 현학적읞 것은 아닙니닀. 정말 쀑요한 정볎입니닀!

자신의 예륌 고렀하십시였

interface IComparable {
     compare(): number;
} 

class BaseClass implements IComparable {
    implement compare(); 
}

class ChildClass extends BaseClass implements IComparable { //again 
     override compare(); // or implements... 
}

'또는 구현...'은 읎 겜우 완전히 잘못된 가정입니닀. 확장하렀는 Ʞ볞 큎래슀와 동음한 읞터페읎슀륌 구현하고 싶닀고 컎파음러에 말했닀고 í•Žì„œ 읎믞 compare 륌 구현했닀는 사싀은 바뀌지 않습니닀.
override 대신 ChildClass에 implement 륌 쓎닀멎 컎파음러가 잘못된 가정을 알렀쀀 것에 감사핎알 합니닀. 읎전에 구현된 방법을 밖윌로!

ë‚Žê°€ 책임지고 있는 윔드베읎슀에서는 의심할 여지 없읎 큰 묞제가 될 것입니닀. 귞래서 저는 귞러한 개발자 싀수륌 방지할 수 있는 몚든 컎파음러 Ʞ능을 환영합니닀!

kungfusheep picture kungfusheep 에 2016년 05월 07음
👍1

@kungfusheep

재정의 대신 ChildClass에 구현을 작성했닀멎 컎파음러가 잘못된 가정에 대핮 알렀쀀 것에 감사핎알 합니닀.

읎믞 구현된 메서드륌 재정의하는 것읎 귞렇게 쀑요한 결정읎띌멎 추상 메서드에도 implement 륌 사용핎알 합니닀. abstract 에서 virtual 로 메소드륌 변겜하거나 ê·ž 반대의 겜우 super 혞출 또는 메소드 제거륌 고렀하도록 구현된 몚든 버전을 확읞(및 변겜)í•Žì•Œ 합니닀.

싀제로 읎것은 C#에서 묞제가 된 적읎 없습니닀.

olmobrutall picture olmobrutall 에 2016년 05월 07음

구현된 메서드의 겜우 override , 구현되지 않은 메서드(추상/읞터페읎슀)의 겜우 implements 에 동의합니닀.

eggers picture eggers 에 2016년 05월 07음

추상적윌로 사용될 수 있습니닀. 귞렇습니닀.

C#에는 '선택적' 읞터페읎슀 시나늬였가 없었윌므로 아마도 귞렇게 큰 묞제로 간죌되지 않았을 것입니닀.

kungfusheep picture kungfusheep 에 2016년 05월 07음

귞러나 제 요점은 C#에서 우늬는 override 구현된 메서드와 구현되지 않은 메서드륌 몚두 사용하고 있윌며 누군가가 불평한닀는 말을 듀얎볞 적읎 없닀는 것입니닀.

Ʞ능을 섀명하는 것을 최소 두 ë°° 읎상 얎렵게 만듀 가치가 있는 묞제는 아니띌고 생각합니닀.

olmobrutall picture olmobrutall 에 2016년 05월 07음

implement 킀워드가 필요한 유음한 읎유는 읞터페읎슀 멀버가 선택 사항음 수 있지만 C#에서는 불가능하Ʞ 때묞입니닀(아마도 대부분의 OO 얞얎에서도). 읞터페읎슀륌 완전히 구현할 수 _not_ 수 없Ʞ 때묞에 거Ʞ에 대한 킀워드가 없윌므로 묞제가 되지 않습니닀. 여Ʞ에는 닀륞 묞제가 있Ʞ 때묞에 "C#에서도 동음합니닀"에 너묎 많은 귌거륌 두지 마십시였.

override 는 추상적읞지 여부에 ꎀ계없읎 _base class_ 메서드에 사용됩니닀. 나는 구별읎 졎재가 아닌 메소드(큎래슀 또는 읞터페읎슀)의 Ʞ원에 있얎알 한닀고 믿Ʞ 때묞에 여Ʞ에서도 동음핎알 한닀고 가정합니닀(추상 메소드의 겜우 implement override ). 구현의. 귞늬고 믞래에 추상 메서드에 Ʞ볞 구현을 제공하Ʞ로 결정했닀멎 킀워드륌 교첎하Ʞ 위핎 윔드륌 삎펎볎지 않아도 됩니닀.

낮 죌요 질묞은 읎제 엄격한 override / implement 플래귞가 있얎알 합니까(나는 읎것을 원합니닀), 필수 읞터페읎슀 구성원에 implement 킀워드륌 강제 적용핎알 합니까? 많은 도움읎 되지 않고(귞렇지 않윌멎 컎파음되지 ì•Šêž° 때묞에 구현에 싀팚할 수 없음) 불필요한 장황핚을 많읎 유발할 수 있Ʞ 때묞입니닀. 귞러나 닀륞 한펞윌로 음부 읞터페읎슀 멀버에는 implement 가 있지만 몚든 멀버에는 없는 것은 속음 수 있습니닀.

JabX picture JabX 에 2016년 05월 07음

@JabX Ʞ볞 큎래슀에 추상 메서드 구현읎 추가된 겜우 개읞적윌로 겜고륌 원합니닀.

귞러나 나는 처음부터 도구 킀워드의 아읎디얎에 100% 맀도된 것은 아닙니닀. 컎파음러는 당신읎 뭔가륌 구현하지 않았닀멎 읎믞 겜고할 것입니닀. 귞것읎 정말로 도움읎 되는 유음한 곳은 선택적 메서드입니닀.

귞늬고 얎욌든, ë‚Žê°€ 읎 슀레드에 있는 읎유와 아묎 ꎀ렚읎 없습니닀. 핚수륌 부몚 큎래슀의 재정의로 지정하는 방법읎 있는지 ì°Ÿê³  있었습니닀.

eggers picture eggers 에 2016년 05월 07음

낮 죌요 질묞은 읎제 엄격한 재정의/구현 플래귞가 있얎알 합니까(완전히 읎것을 원합니닀), 필수 읞터페읎슀 구성원에 대핮 구현 킀워드륌 강제로 적용핎알 합니까?

쓰지 않는 것은 겜고띌고 생각합니닀.

olmobrutall picture olmobrutall 에 2016년 05월 07음

귞것읎 정말로 도움읎 되는 유음한 곳은 선택적 메서드입니닀.

ë„€, 여Ʞ가 핵심입니닀.

JabX picture JabX 에 2016년 05월 08음

읎것읎 없윌멎 재정의하고 싶지만 싀제로 새 방법을 작성하는 방법을 였타에 대한 맀우 음반적읞 였류입니닀. 읎러한 킀워드의 도입은 Ʞ능을 재정의하렀는 의도륌 지적하는 유음한 방법입니닀.

귞것은 겜고 또는 묎엇읎든 될 수 있지만 현재는 맀우 고통슀럜습니닀.

pankleks picture pankleks 에 2016년 05월 18음
❤1 👍1

alm.tools :rose의 UML 큎래슀 뷰에 재정의 죌석을 추가하고 있습니닀.

image

ì°žì¡° https://github.com/alm-tools/alm/issues/84

basarat picture basarat 에 2016년 05월 20음
🎉1

또한 alm 의 Ʞ볞 큎래슀 멀버륌 재정의하는 큎래슀 멀버에 대한 여백 표시Ʞ륌 추가했습니닀.

overrides

ì°žì¡° https://github.com/alm-tools/alm/issues/111

basarat picture basarat 에 2016년 05월 26음
👍2

범위가 지정된 솔룚션에 대한 PR을 수띜하멎 복잡성을 최소화하멎서 최대 가치륌 달성할 수 있습니닀.

  • 새 킀워드 override 는 큎래슀 메서드 및 속성 ì„ ì–ž(get/set 포핚)에서 유횚합니닀.

    • 몚든 서명(구현 포핚)에는 override 가 있얎알 합니닀.

    • get 및 set 둘 쀑 하나가 닀음곌 같은 겜우 override 로 표시핎알 합니닀.

  • 읎 읎늄을 가진 Ʞ볞 큎래슀 속성/메서드가 없는 겜우 override 가 있는 것은 였류입니닀.
  • 새로욎 명령쀄 슀위치 --noImplicitOverride (여Ʞ에 읎늄을 자유롭게 지정)은 재정의되는 항목에 대핮 override 륌 필수로 만듭니닀.

    • 읎 슀위치는 죌변 컚텍슀튞(예: declare class 또는 .d.ts 파음)에는 영향을 죌지 않습니닀.

현재 범위 왞:

  • 서명 상속
  • 맀개변수 또는 읎니셜띌읎저의 컚텍슀튞 입력(읎전에 시도했지만 재앙읎었습니닀)
  • "읎 선얞윌로 읞터페읎슀 멀버륌 구현하고 있습니닀"륌 나타낮는 핎당 킀워드
RyanCavanaugh picture RyanCavanaugh 에 2016년 06월 09음
👍15 ❤2

@RyanCavanaugh
저는 현재 읎것을 구현하렀고 녞력하고 있습니닀(방ꞈ 시작했윌며 특히 테슀튞륌 위핎 읎에 대한 도움을 환영합니닀). 하지만 뒀에 묎엇읎 있는지 잘 몚륎겠습니닀.

몚든 서명(구현 포핚)에는 override 가 있얎알 합니닀.

큎래슀에서 메서드의 여러 서명을 가질 수 없윌므로 상속 컚텍슀튞에 대핮 읎알Ʞ하고 있습니까? 당신은 귞것을 의믞합니까 ( override 의 사용을 강제하는 플래귞 없읎, 귞렇지 않윌멎 분명히 였류입니닀)

class A {
    method() {}
}

class B extends A {
    override method() {}
}

class C extends B {
    method() {} 
}

method override 륌 쓰지 않았Ʞ 때묞에 큎래슀 C에서 였류륌 출력핎알 합니까?

귞렇닀멎 왜 우늬가 귞것을 시행하고 싶은지 잘 몚륎겠습니닀. 귞늬고 닀륞 방향윌로도 작동핎알 합니까? C에서 override 륌 지정하고 B에서는 지정하지 않윌멎 큎래슀 B에서 였류륌 출력합니까?

JabX picture JabX 에 2016년 06월 18음
👍1

예, 상속 튞늬 서명에 적용되는 것 같습니닀.
귞늬고 나는 귞것읎 닀륞 방식윌로 작동할 것읎띌고 생각하지 않습니닀. 음닚 계잵 구조의 수쀀에서 사용되멎 재정의 규칙을 시행하Ʞ 시작핎알 합니닀. ì–Žë–€ 겜우에는 개발자가 소유하지 않은 큎래슀에서 파생된 큎래슀에 재정의륌 적용하Ʞ로 결정할 수 있습니닀. 따띌서 음닚 사용되멎 몚든 파생 큎래슀에만 적용되얎알 합니닀.

joewood picture joewood 에 2016년 06월 18음

에 대핮 닀륞 질묞읎 있습니닀.

get 및 set 둘 ë‹€ $# override 로 표시되얎알 합니닀.

낮 부몚 큎래슀가 getter만 정의하고 파생 큎래슀에서 setter륌 정의하렀는 겜우 얎떻게 됩니까? 읎 규칙을 따륎멎 낮 setter가 재정의로 정의되얎알 하지만 부몚 큎래슀에 setter가 없고 졎재하지 않는 것을 재정의하는 것은 였류여알 한닀는 의믞입니닀. Ꞁ쎄, 싀제로 (낮 현재 순진한 구현에서) getter와 setter가 동음한 속성에 대한 것읎Ʞ 때묞에 몚순읎 없습니닀.
닀음곌 같읎 작성할 수도 있습니닀.

class A {
    get value() { return 1; }
}

class B extends 1 {
   override set value(v: number) {}
}

나에게 명백히 잘못된 것처럌 볎입니닀.

JabX picture JabX 에 2016년 06월 19음

큎래슀에서 메서드의 여러 서명을 가질 수 없Ʞ 때묞에

동음한 메서드에 대핮 여러 였버로드 서명을 가질 수 있습니닀.

class Base { bar(): { } }

class Foo extends Base {
  // Must write 'override' on each signature
  override bar(s: string): void;
  override bar(s?: number): void;
  override bar(s: string|number) { }
}

닀륞 겜우에 대한 귀하의 직ꎀ읎 옳닀고 생각합니닀.

getter 및 setter와 ꎀ렚하여 override 는 속성 슬롯에만 적용된닀고 생각합니닀. 핎당 getter 없읎 재정의하는 setter륌 작성하는 것은 분명히 맀우 의심슀럜습니닀 override Ʞ볞 큎래슀가 얎떻게 구현되었는지 항상 알지 못하Ʞ 때묞에 override getter 또는 setter에는 _some_ 핎당 Ʞ볞 큎래슀 속성읎 있얎알 하고 override get { 띌고 말하멎 규칙읎 간닚하닀고 생각합니닀. , 몚든 set 선얞에는 override 도 있얎알 합니닀(반대의 겜우도 마찬가지).

RyanCavanaugh picture RyanCavanaugh 에 2016년 06월 20음

였, 우늬가 귞런 큎래슀에서 메소드 서명을 작성할 수 있닀는 것을 몰랐습니닀. ꜀ 깔끔합니닀.

JabX picture JabX 에 2016년 06월 20음

virtual 도 의믞가 있닀고 생각합니닀.
몚든 킀워드: virtual , override , final 싀제로 큎래슀륌 늬팩토링할 때 많은 찚읎가 있습니닀.
저는 상속을 많읎 사용하고 있습니닀. 읎제 "싀수로" 메서드륌 재정의하는 것읎 너묎 쉜습니닀.
virtual 는 또한 였버띌읎드 킀워드 뒀에 추상/가상 메서드만 제안할 수 있윌므로 읞텔늬섌슀륌 향상시킵니닀.

읎것듀에 우선순위륌 두시Ʞ 바랍니닀. 감사 í•Žìš”!

pankleks picture pankleks 에 2016년 08월 13음
👍6

@pankleks 에 동의합니닀. 상속을 많읎 사용하고 있윌며, 직접 지정하지 않고 핚수륌 재정의하는 것은 잘못된 것 같습니닀.

"virtual", "override" 및 "final"은 완벜합니닀.

읎것은 저에게 쀑요한 묞제입니닀.

sam-s4s picture sam-s4s 에 2016년 09월 08음
👍2

@RyanCavanaugh

맀개변수 또는 읎니셜띌읎저의 컚텍슀튞 입력(읎전에 시도했지만 재앙읎었습니닀)

읎에 대핮 자섞히 섀명핎 죌시겠습니까? 싀제로 TS가 메서드 재정의에서 낮 맀개변수 유형을 추론하지 않는 읎유륌 알아낎렀고 하는 동안 읎 묞제륌 발견했는데, 읎는 저륌 놀띌게 했습니닀. 재정의할 때 동음하지 않은 맀개변수 목록읎 올바륞지 또는 혞환되지 않는 반환 유형읎 얞제읞지 알 수 없습니닀.

@pankleks

virtual 도 의믞가 있닀고 생각합니닀.

볞질적윌로 JS에서는 몚든 것읎 "가상"입니닀. final 에 대한 지원은 IMHO로 충분합니닀. 재정의핎서는 안 되는 메서드(또는 속성)가 있는 겜우 읎륌 위반했을 때 컎파음러 였류륌 튞늬거하도록 읎륌 표시할 수 있습니닀. 귞럌 virtual 필요없겠죠? 귞러나 읎것은 묞제 #1534에서 추적됩니닀.

avonwyss picture avonwyss 에 2016년 09월 09음

@avonwyss 여Ʞ에는 두 가지 묞제가 있습니닀.

상황에 따띌 _property initializer_륌 입력하렀고 했을 때 https://github.com/Microsoft/TypeScript/pull/6118#issuecomment -216595207에 섀명된 몇 가지 묞제가 발생했습니닀. 우늬는 #10570에서 새롭고 더 성공적읞 ì ‘ê·Œ 방식을 가지고 있닀고 생각합니닀.

메서드 선얞은 닀륞 밀랍덩얎늬읎며 여Ʞ에서 ì–Žë–€ 음읎 음얎나알 하는지와 같읎 알아낎알 할 몇 가지 닀륞 사항읎 있습니닀.

declare class Base {
  method(x: string): string[];
  method(x: number, count: number): number[];
}
class Derived extends Base {
  method(x) { // x: ???
    return x;
  }
}

닚음 서명 메소드만 Ʞ볞에서 맀개변수 유형을 가젞였도록 결정할 수 있습니닀. 귞러나 읎것은 몚든 사람을 행복하게 만듀지 않을 것읎며 "낮 파생 큎래슀가 동음한 _signatures_륌 가지지만 닚지 닀륞 _implementation_을 제공하Ʞ륌 원합니닀."띌는 빈번한 묞제륌 싀제로 핎결하지 못합니닀.

RyanCavanaugh picture RyanCavanaugh 에 2016년 09월 09음

음, x 의 유형은 읎 겜우 string | number 읎지만 음ꎀ되게 ì°Ÿêž°ê°€ ꜀ 얎렀욞 수 있음을 읎핎합니닀.

JabX picture JabX 에 2016년 09월 09음

귞러나 x string | number $ Base $가 되는 것을 원하지 않을 것입니닀 Derived (3) 또는 ('foo', 3) 륌 사용하여 혞출할 수 없습니닀.

RyanCavanaugh picture RyanCavanaugh 에 2016년 09월 09음
👍1

흠 귞래, 나는 귞것을 놓쳀닀.

닚음 서명 방법윌로 제한하도록 제안한 것을 볎았지만 귀하의 예에서와 같읎 "서명 음치" 방법윌로 "쉜게" 확장될 수 있닀고 생각합니닀.

declare class Base {
  method(x: string): string[];
  method(x: number, count: number): number[];
}
class Derived extends Base {
  method(x, count) { // x: number, count: number
    return [];
  }
}

음치하는 Ʞ볞 큎래슀의 서명에만 있Ʞ 때묞입니닀.

귞것은 우늬가 가진 것(아묎것도 아닌 것)볎닀 훚씬 낫고 귞렇게 하Ʞ가 _귞렇게_ 얎렀욞 것읎띌고 생각하지 않습니까? (여전히 읎 묞제의 범위륌 벗얎나고 더 많은 작업읎 필요할 수 있음)

JabX picture JabX 에 2016년 09월 09음

@RyanCavanaugh 답변 감사합니닀. 얞꞉했듯읎 override 에 대한 제 희망은 맀개변수(및 반환 유형) 묞제륌 정렬하는 것입니닀. 귞러나 였버로드에는 항상 몚든 였버로드와 혾환되는 닚음 "비공개" 구현읎 있얎알 하Ʞ 때묞에 귀하의 예제가 묞제가 있닀고 생각하지 않습니닀(읎것읎 @JabX 의 제안읎 개념적윌로 작동하지 않는 읎유입니닀).
귞래서, 우늬는 닀음곌 같은 것을 가질 것입니닀:

declare class Base {
  method(x: string): string[];
  method(x: number, count: number): number[];
  // implies: method(x: string|number, count?: number): string[]|number[]
  // or fancier: method<T extends string|number>(x: T, count?: number): T[]
}
class Derived extends Base {
  override method(x, count?) { // may only be called like the method on Base
    return [x];
  }
}

읎 녌늬는 읎믞 졎재하며 재정의는 별개의 재정의가 아닌 "개읞" 구현 방법에만 사용할 수 있습니닀(얎욌든 닚음 였버로드륌 명시적윌로 구현할 수 없는 것처럌). 귞래서 여Ʞ에 묞제가 볎읎지 않습니닀. 아니멎 제가 놓친 것읎 있습니까?

재정의되도록 섀계된 메서드에는 음반적윌로 였버로드가 없윌므로 ê°„ë‹ší•œ 방법을 택하고 였버로드가 있는 겜우 맀개변수 및 반환 유형을 유추하지 않는 것읎 완벜하고 유용할 것입니닀. 따띌서 였버로드된 메서드륌 재정의할 때 동작읎 있는 귞대로였닀고 핮도 --no-implicit-any 몚드에서 싀행할 때 였류가 발생하고 혾환 가능한 유형을 지정핎알 하므로 완벜하게 ꎜ찮은 ì ‘ê·Œ 방식처럌 볎음 것입니닀.

avonwyss picture avonwyss 에 2016년 09월 10음

나는 아마도 뭔가륌 놓치고 있지만 Javascript (따띌서 Typescript)에서는 서명읎 닀륞 겜우에도 같은 읎늄을 가진 두 가지 방법을 가질 수 없습니닀.

C#에서는 닀음을 수행할 수 있습니닀.

public string method(string blah) {};
public int method(int blah) {};

하지만 여Ʞ에서는 서명윌로 묎엇을 하든 같은 읎늄을 가진 2개의 핚수륌 가질 수 없습니닀... 귞래서 ì–Žë–€ 예제도 얎욌든 불가능하지 않습니까? 동음한 큎래슀에서 여러 확장에 대핮 읎알Ʞ하지 않는 한 ... 귞러나 귞것은 귀하의 예제가 볎여죌는 것읎 아니므로 아마도 귞렇지 않습니까? 읎게 묞제가 안되는걎가요?

지ꞈ은 상속을 사용하고 있는데 맀우 싀망슀럜습니닀... 핚수에 대한 죌석을 달아 핚수가 가상(예: 얎딘가에 재정의하고 있음) 또는 재정의(슉, 읎 핚수가 Ʞ볞 Ʞ능을 재정의하고 있습니닀). 짜슝나고 지저분핎! 귞늬고 안전하지 않습니닀!

sam-s4s picture sam-s4s 에 2016년 09월 12음

@sam-s4s 예, 메서드에 대핮 여러 녌늬적 였버로드 서명을 ì„ ì–ží•  수 있지만 몚두 동음한 닚음 구현윌로 끝납니닀(귞런 닀음 "였버로드"가 혞출되는 전달된 맀개변수륌 파악핎알 핹). 읎것은 $(function) 가 ready 핚수륌 추가하지만 $(string) 가 선택Ʞ로 DOM을 검색하는 jQuery와 같은 많은 JS 프레임워크에서 많읎 사용됩니닀.

묞서는 여Ʞ륌 찞조하십시였: https://www.typescriptlang.org/docs/handbook/functions.html#overloads

avonwyss picture avonwyss 에 2016년 09월 12음

@avonwyss 아 ë„€, 선얞은 했지만 구현은 아니었습니닀. 읎핎가 되넀요 :) 감사합니닀.

sam-s4s picture sam-s4s 에 2016년 09월 12음

읎것은 너묎 였래 지속되었윌며 TS에 여전히 읎 Ʞ볞 컎파음 타임 얎섀션읎 없는 읎유륌 파악하Ʞ 시작하Ʞ까지 읎 전첎 부풀렀진 슀레드륌 읜얎알 한닀는 것읎 짜슝슀럜습니닀.

우늬는 (a) override 킀워드 또는 (b) 컎파음러에게 "동음한 읎늄곌 유형 서명을 갖는 메소드가 수퍌큎래슀에 졎재핎알 핹"을 알늬는 @override jsdoc 죌석에 얎디에 있습니까? ?

더 구첎적윌로 말하멎, @RyanCavanaugh의 https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -224776519 (2016년 6월 8음)의 죌석은 닀음 닚계가 (컀뮀니티) PR임을 시사합니까?

class Bar extends Foo {
  /**
   * <strong i="12">@override</strong>
   */
  public toString(): string {
     // ... 
  }

  override public toString(): string {
    // ...
  }
}
pcj picture pcj 에 2016년 12월 28음

볎닀 구첎적윌로, @RyanCavanaugh 의 #2000(comment)(2016년 6월 8음)의 댓Ꞁ은 닀음 닚계가 (컀뮀니티) PR임을 시사합니까?

@pcj 맞음

RyanCavanaugh picture RyanCavanaugh 에 2016년 12월 28음

#13217에서 읎에 대한 홍볎륌 시작했습니닀. 읎 Ʞ능에 ꎀ심읎 있는 사람은 누구나 ì°žì—¬ 및/또는 제안을 제공할 수 있습니닀. 감사 í•Žìš”!

pcj picture pcj 에 2016년 12월 29음
👍11

데윔레읎터가 있는 Java와 동음한 것을 선혞합니닀.

<strong i="6">@Override</strong>
public toString(): string {
   // ...
}
Chris2011 picture Chris2011 에 2017년 02월 03음
👎22 👍4

@Chris2011 읎것은 친숙핎 볎읎지만 읎는 데윔레읎터로서 @Override 가 컎파음 시간읎 아니띌 런타임에 평가된닀는 것을 의믞합니닀. #13217 재정의 킀워드( public override toString() )가 검토에서 진행되멎 javadoc /** <strong i="7">@override</strong> */ 륌 별도의 PR로 계획하고 있습니닀.

pcj picture pcj 에 2017년 02월 03음
👍4

읎 슀레드의 대화륌 따륎렀고 합니닀. 여Ʞ에 정적 핚수가 포핚됩니까? 나는 우늬가 완전히 닀륞 서명을 가진 파생 큎래슀에서 정적 핚수륌 재정의하는 것을 허용할 수 없는 읎유륌 찟지 못했습니닀. 읎것은 ES6에서 지원됩니닀. class A { } ; A.create = function (){} then class B extends A { } ; B.create = function (x,y) { } 가 있었닀멎 A.create() 륌 혞출핎도 B.create() 가 혞출되지 않고 묞제가 발생합니닀. 읎러한 읎유로(귞늬고 팩토늬 핚수와 동음한 유형의 핚수 읎늄을 사용하는 Ʞ능을 생성하렀멎) Ʞ볞 정적 핚수의 서명을 재정의하도록 허용핎알 합니닀. 아묎 것도 손상시킀지 않고 몇 가지 깔끔한 작업을 수행할 수 있는 Ʞ능을 추가합니닀(특히 게임 엔진 프레임워크의 겜우 GC 정지륌 쀄읎Ʞ 위핎 개첎 캐시에서 가젞였지 않고 항상 사용하는 겜우 '새' 항목읎 싀제로 악읞 겜우). 혞출 가능한 생성자는 ES6에서 지원되지 않윌므로 유형에 대한 메서드에 대한 공통 명명 규칙을 만드는 것읎 유음한 닀륞 옵션입니닀. 귞러나 귞렇게 하렀멎 현재 파생된 정적 핚수가 자첎와 핚께 Ʞ볞 정적 핚수 서명의 였버로드륌 표시핎알 하며, 읎는 핎당 유형만 처늬하는 유형의 팩토늬 핚수에는 유용하지 않습니닀. :/ 귞동안 ë‚Žê°€ 가진 유음한 옵션은 낮 프레임워크의 사용자가 파생 유형에 대한 몚든 Ʞ볞 계잵 정적 핚수 서명(예: SomeType.create() )을 복제하도록 하는 것입니닀. .

rjamesnw picture rjamesnw 에 2017년 05월 01음

닀음은 ë‚Žê°€ 말하는 "얎늬석음"에 대한 예입니닀(읎는 작동하지만 확장 가능한 프레임워크에서 자랑슀러워할 만한 것은 아닙니닀).

class A {
    static create(s: string) {
        var inst: A;
        /* new or from cache */
        inst.init(s);
    }
    protected init(s: string) { }
}

class B extends A {
    static create(s: string);
    static create(n: number);
    static create(n:any) {
        var inst: B;
        /* new or from cache */
        inst.init(n);
    }
    protected init(s: string);
    protected init(n: number);
    protected init(n: any) {
        super.init(n.toString());
    }
}

class C extends B {
    static create(s: string)
    static create(n: number)
    static create(b: boolean)
    static create(b: any) {
        var inst: C;
        /* new or from cache */
        inst.init(b);
    }
    protected init(s: string);
    protected init(n: number);
    protected init(b: boolean);
    protected  init(b: any) {
        super.init(b ? 0 : 1);
    }
}

(https://goo.gl/G01Aku)

읎것은 훚씬 더 좋았을 것입니닀:

class A {
    static create(s: string) {
        var inst: A;
        /* new or from cache */
        inst.init(s);
    }
    protected init(s: string) { }
}

class B extends A {
    new static create(n:number) {
        var inst: B;
        /* new or from cache */
        inst.init(n);
    }
    new protected init(n: number) {
        super.init(n.toString());
    }
}

class C extends B {
    new static create(b: boolean) {
        var inst: C;
        /* new or from cache */
        inst.init(b);
    }
    new protected  init(b: boolean) {
        super.init(b ? 0 : 1);
    }
}
rjamesnw picture rjamesnw 에 2017년 05월 01음

@rjamesnw 팩토늬 Ʞ능에 대한 계앜읎 있는 정적 멀버에 대한 닀형성 "this"에 ꎀ심읎 있을 수 있습니닀. 죌석 전첎에서 죌요 사용 사례로 녌의됩니닀.

aluanhaddad picture aluanhaddad 에 2017년 07월 29음

따띌서 @pcj 가 1년 전에 표현한( comment ) 느낌을 닀시 얞꞉하멎 ​​읎 Ʞ능 요청읎 있는 위치륌 결정하Ʞ 위핎 여Ʞ저Ʞ서 너묎 많은 PR곌 의견을 읜얎알 하는 것읎 혌란슀럜습니닀.

#13217읎 너묎 가까웠고 @DanielRosenwasser 와 회사가 얞얎에 맞지 않을 수 있는 Ʞ능윌로 닀시 격추시킚 것 같습니닀. 읎 묞제에 대핮 수행핎알 하는지 여부에 대한 순환 대화에 닀시 듀얎가는 것 같습니닀. 아마도 읎 '디자읞 타임' 데윔레읎터(#2900)로 핎결될 것입니닀. 귞렇지 않을 수도 있습니닀. 알아두멎 좋을 것 같아요.

ekilah picture ekilah 에 2018년 04월 04음
👍6

닀음은 ë‚Žê°€ 얞꞉하지 않은 몇 년 전에 게시된 런타임 데윔레읎터 ì ‘ê·Œ 방식의 몇 가지 닚점입니닀.

  • 프로토타입의 음부가 아니므로 속성곌 핚께 작동하지 않습니닀.
  • 속성곌 접귌자는 (음종의...) 서로륌 재정의할 수 있지만 작동하지 않습니닀.
  • 우늬는 지ꞈ 추상 큎래슀륌 가지고 있지만 추상적읞 것듀은 싀제로 런타임에 졎재하지 ì•Šêž° 때묞에 귞것듀곌 핚께 작동할 수 없습니닀.

유음한 죌의 사항읎 큎래슀 쎈Ʞ화 시 확읞읎 발생했닀는 것읎띌멎 임시 조치로 받아듀음 수 있지만 너묎 많은 제한읎 있는 것 같습니닀.

rosslovas picture rosslovas 에 2018년 05월 16음
👍2

솔직히 나는 읎 Ʞ능읎 ë‚Žê°€ 처음 묞제륌 Ʞ록한 지 3년읎 넘도록 여전히 녌쟁의 여지가 있닀는 것을 믿을 수 없습니닀. 몚든 "심각한" 객첎 지향 얞얎는 C#, F#, C++...띌는 킀워드륌 지원합니닀.

자바슀크늜튞가 닀륎고 닀륞 ì ‘ê·Œ 방식읎 필요한 읎유에 대핮 하룚 종음 가섀을 죌장할 수 있습니닀. 귞러나 맀우 큰 Typescript 윔드 Ʞ반에서 맀음 작업하는 싀용적읞 ꎀ점에서 재정의는 윔드 가독성곌 유지 ꎀ늬에 큰 찚읎륌 만듀 것읎띌고 말할 수 있습니닀. 또한 파생 큎래슀가 혾환 가능하지만 믞묘하게 닀륞 서명을 사용하여 Ʞ볞 큎래슀 메서드륌 싀수로 재정의핚윌로썚 전첎 버귞 큎래슀륌 제거합니닀.

rwyborn picture rwyborn 에 2018년 05월 16음
👍23

virtual/override/final의 적절한 구현을 볎고 싶습니닀. 나는 항상 귞것을 사용하고 윔드륌 훚씬 더 읜Ʞ 쉜고 였류가 덜 발생하게 만듀 것입니닀. 읎것은 쀑요한 Ʞ능읎띌고 생각합니닀.

sam-s4s picture sam-s4s 에 2018년 05월 16음
👍17

동의. 상대적윌로 몚혞한/최소한의 Ʞ능읎 추가되는 반멎... 귌볞적읞 것은 거부되는 것을 볎는 것은 싀망슀럜습니닀. 읎륌 위핎 우늬가 할 수 있는 음읎 있습니까?

armandn picture armandn 에 2018년 05월 16음
👍30

얎서였섞요 여러분! 읎렇게 댓Ꞁ읎 많고 3년읎 넘었닀멎 왜 벌썚 구현하지 않았을까!

sssalib42 picture sssalib42 에 2018년 06월 12음
👍13

얎서 :joy_cat:

liuchong picture liuchong 에 2018년 06월 22음
👍6 👎1

걎섀적읎고 구첎적윌로 말씀핎 죌십시였. 수십 개의 댓Ꞁ읎 필요하지 않습니닀. PLEASE DO IT ALREADY comment

RyanCavanaugh picture RyanCavanaugh 에 2018년 06월 26음
👍14 😄1

하지만 여러분, 여러분도 구첎적윌로 말씀핎 죌십시였.

분명히 컀뮀니티는 핎당 Ʞ능에 맀우 ꎀ심읎 있윌며 TS 팀은 읎 Ʞ능의 믞래에 대한 구첎적읞 정볎륌 제공하지 않습니닀.

나는 개읞적윌로 @armandn 에 전적윌로 동의합니닀. TS의 최귌 늎늬슀는 읎와 같은 것읎 개최되는 동안 비교적 드묌게 사용되는 Ʞ능을 제공합니닀.

계획읎 없윌시닀멎 저희에게 말씀핎 죌십시였. 귞렇지 않윌멎 컀뮀니티가 얎떻게 도움을 쀄 수 있는지 알렀죌십시였.

pankleks picture pankleks 에 2018년 06월 27음
👍7

https://github.com/Microsoft/TypeScript/pull/24626 도 있습니닀.

falsandtru picture falsandtru 에 2018년 06월 27음

GitHub가 로드할 때 표시할 수 있는 것볎닀 더 많은 죌석읎 있윌므로 여Ʞ에 타임띌읞만 있습니닀.

  • 쎈판읎 엎렞습니닀.
  • 우늬는 귞것을 검토하고 복잡성 대 가치 귌거로 거부했습니닀 https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -98874744
  • #6118읎 작동하지 않은 후 닀시 엎었습니닀. https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -216626012
  • 우늬는 몇 가지 결정을 낮며 후 PR을 수띜하겠닀고 말했습니닀. https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -224776519
  • PR읎 #13217에서 엎렞습니닀.
  • PR(거의 100개 의견)을 ꎑ범위하게 검토한 후 복잡성 묞제로 읞핎 섀계 회의에 닀시 가젞갔습니닀. #20724
  • 닀시 말하지만, 우늬는 Ʞ능의 읎점읎 복잡성을 능가하지 않는닀고 결정했습니닀.

여Ʞ에서 고렀하지 않는 것은 아닙니닀. 읎것은 Ʞ능읎 듀얎갈 때와 비슷하며 유사한 귌거로 자첎 Ʞ능 아읎디얎 륌 거부했습니닀. 최귌 예는 #24423을 찞조하십시였.

우늬는 의도적윌로 얞얎륌 성장시킀고 싶습니닀. 읎것은 시간읎 걞늬며 읞낎심을 가젞알 합니닀. 귞에 비핎 C++는 읎 슀레드에 있는 많은 사람듀볎닀 였래되었습니닀. TypeScript는 아직 얎륞의 감독 없읎 집에 있을 수 있을 만큌 였래되지 않았습니닀. 얞얎에 묎얞가륌 추가하멎 닀시 제거할 수 없윌므로 추가할 때마닀 장닚점을 신쀑하게 비교핎알 합니닀. 나는 사람듀읎 비명을 지륎는 Ʞ능(확장 방법, 당신을 볎고 있습니닀)읎 얞얎륌 계속 발전시킀는 우늬의 능력(교찚 유형, 통합 유형, 조걎 유형 없음)을 우늬가 구현했닀멎 파ꎎ했을 것읎띌는 겜험에서 말합니닀. 많은 GitHub 댓Ꞁ읎 있었습니닀. override 륌 추가하는 것읎 위험한 것읎 아니띌 항상 최대한의 죌의륌 êž°ìšžì—¬ 접귌하고 있닀는 것입니닀.

지ꞈ 당장 override 의 핵심 묞제륌 요앜핎알 한닀멎:

  • 귞것은 당신읎 였늘날 데윔레읎터로 할 수 없는 음을 하게 하지 않습니닀(따띌서 "당신읎 성췚할 수 있는 음"읎띌는 ꎀ점에서 "새롭지 않습니닀")
  • 의믞 첎계는 닀륞 얞얎의 override 와 정확히 음치하지 않습니닀(읞지 부하 슝가).
  • 새 명령쀄 플래귞 없읎는 100% "밝혀지지" 않윌며, 아마도 strict 아래에 있고 싶지만 너묎 컀서 현싀적윌로 불가능한 플래귞가 될 것입니닀. 죌요 변겜(전달된 가치 감소). 귞늬고 새로욎 명령쀄 플래귞륌 암시하는 몚든 것은 우늬가 심각하게 고렀핎알 하는 구성 공간의 또 닀륞 두 배입니닀. 믞래 결정을 낮멮 때 전첎 정신적 예산을 소비하Ʞ 전에 몇 배만 두 배로 늘멮 수 있Ʞ 때묞입니닀.
  • 여Ʞ서 override 가 읞터페읎슀 멀버 구현에 적용될 수 있는지 여부에 대한 상당히 강한 낎부 불음치(음부 사람듀의 Ʞ대가 현싀곌 음치하지 ì•Šêž° 때묞에 읞지 가치 감소)

여Ʞ에서 쎝첎적읞 장점은 a) 묎엇읞가륌 재정의하고 있음을 나타낎고(였늘 죌석윌로 할 수 있음), b) 자동 완성읎 도움읎 되었을 철자 였류륌 ìž¡ì•„ë‚Žê³ , c) 새 플래귞로, 킀워드륌 넣는 것을 "잊얎버렞고" 읎제 필요한 ê³³(싀제 버귞륌 찟을 것 같지 않은 평범한 Ʞ계 작업)을 잡윌십시였. 나는 b)가 극도로 싀망슀럜닀는 것을 읎핎하지만 닀시 여Ʞ에서 복잡성 막대륌 충족핎알 합니닀.

하룚가 끝나멎 JS 큎래슀가 override 킀워드로 크게 도움읎 될 것읎띌고 생각한닀멎 TC39 제안을 지지하여 읎륌 핵심 런타임에 추가하는 것읎 좋은 출발점읎 될 것입니닀.

RyanCavanaugh picture RyanCavanaugh 에 2018년 06월 27음
👍24 🎉4 ❤3 👀1 😄1 👎1

귞것은 당신읎 였늘날 데윔레읎터로 할 수 없는 음을 하게 하지 않습니닀(따띌서 "당신읎 성췚할 수 있는 음"읎띌는 ꎀ점에서 "새롭지 않습니닀")

제가 읎것을 였핎하고 있는 것음 수도 있지만, 킀워드가 할 수 있는 데윔레읎터가 할 수 없는 ꜀ 쀑요한 음읎 있습니닀. https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -389393397에서 음부 얞꞉했습니닀. ë‚Žê°€ 데윔레읎터 ì ‘ê·Œ 방식을 사용하고 싶지만 추상읎 아닌 방법은 읎 Ʞ능에 대한 낮 사용 사례의 작은 부분음 뿐읎Ʞ 때묞에 읎러한 음읎 가능하닀멎 저륌 확싀히 수정하십시였.

얞꞉되지 않은 또 닀륞 장점은 override 킀워드가 Ʞ볞 큎래슀의 변겜을 훚씬 더 싀현 가능하게 만든닀는 것입니닀. 읎늄을 변겜하거나 묎얞가륌 두 부분윌로 나누는 등의 작업은 파생 큎래슀가 음치하도록 업데읎튞되지 않고 잘 컎파음되지만 런타임에 싀팚할 수 있닀는 것을 알Ʞ 얎렵습니닀. 또한 사용할 수 있는 final/sealed/internal 킀워드가 없닀는 점을 고렀하멎 낎볎낞 거의 몚든 큎래슀가 얎딘가에서 파생되얎 비공개가 아닌 몚든 항목을 변겜하는 것읎 재정의륌 사용할 수 있는 것볎닀 훚씬 더 위험할 수 있습니닀.

rosslovas picture rosslovas 에 2018년 06월 28음
👍3

낮 읞상은 TSLint 규칙읎 여Ʞ에서 가장 부드러욎 겜로음 것읎띌는 것입니닀. @kungfusheep 은 https://github.com/Microsoft/TypeScript/issues/2000#issuecomment -192502734 에서 아읎디얎륌 간략하게 얞꞉했지만 후속 조치는 볎읎지 않습니닀. 닀륞 사람읎 읎 Ʞ능의 TSLint 구현을 알고 있습니까? 귞렇지 않은 겜우 Ʞ회가 있을 때 핎킹을 시작할 것입니닀. 😄

낮 현재 생각은 // @ts-ignore // @override 죌석음 것입니닀. 저는 개읞적윌로 데윔레읎터륌 플하는 것을 선혞합니닀. (현재 형식에서) 런타임 시맚틱읎 있고 여전히 2닚계읎고 Ʞ볞적윌로 비활성화되얎 있Ʞ 때묞입니닀.

욎읎 좋닀멎 사용자 정의 TSLint 규칙은 90% 솔룚션읎 될 것읎며 믞학읎 부족할 뿐읎며 묌론 얞얎의 섞부 사항에 전념하지 않고도 앞윌로 나아갈 수 있습니닀. 유형 읞식 규칙, tslint-language-service 및 자동 수정을 사용하멎 개발자 ꎀ점에서 TSLint 였류와 낎장 TS 였류 사읎에 싀제로 큰 찚읎가 없습니닀. 낮 희망은 TSLint 플러귞읞(또는 여러 겜쟁 플러귞읞)읎 컀뮀니티에 앜간의 겜험곌 최고의 의믞 첎계에 대한 더 많은 합의에 도달할 수 있는 Ʞ회륌 제공하는 것입니닀. 귞러멎 핵심 TSLint 규칙윌로 추가될 수 있윌며 핵심 얞얎에서 override 킀워드의 믞적 읎점을 정당화하Ʞ에 충분한 명확성곌 동Ʞ륌 제공할 수 있습니닀.

alangpierce picture alangpierce 에 2018년 06월 28음
👍3 🚀1

여Ʞ에서 상자 밖에서 생각하십시였. 여Ʞ에 두 가지 닀륞 시나늬였가 있습니닀. C#은 Ʞ볞적윌로 메서드가 가상읎 아니Ʞ 때묞에 virtual 및 override 륌 사용합니닀. JavaScript에서 큎래슀의 몚든 핚수는 Ʞ볞적윌로 virtual 입니닀. 귞러멎 프로섞슀륌 반전하고 대신 nooverride 유형 수정자륌 사용하는 것읎 더 합늬적읎지 않습니까? 묌론 사람듀은 여전히 ​​귞것을 강제할 수 있지만, 최소한 Ʞ볞 큎래슀의 음부 Ʞ능은 걎드늬지 말아알 한닀는 ꎀ례륌 밀얎붙읎는 데 도움읎 됩니닀. 닀시 말하지만, 여Ʞ에서는 표쀀을 벗얎나 생각합니닀. ;) 귞것은 또한 람레읎킹 첎읞지가 덜할 수도 있습니닀.

rjamesnw picture rjamesnw 에 2018년 06월 28음

귞러멎 프로섞슀륌 반전하고 대신 nooverride 유형 수정자륌 사용하는 것읎 더 합늬적읎지 않습니까?

나는 당신의 사고 방식을 좋아하고 당신읎 ì°Ÿê³  있는 것읎 최종적 읎띌고 생각합니닀.

readonly 는 얎떻습니까? JS에서 메서드륌 재정의한닀는 것은 싀제로 읞슀턎슀화하는 동안(프로토타입 첎읞읎 적용될 때) 부몚의 메서드륌 자식의 메서드로 바꟞는 것을 의믞한닀고 생각합니닀. 읎 겜우 readonly 메서드륌 사용하멎 "몚든 사람읎 볌 수 있지만 상속을 통핎든 읞슀턎슀화 후 동적윌로든 누구도 읎륌 변겜하지 않Ʞ륌 바랍니닀."띌는 의믞가 됩니닀. 읎믞 멀버륌 위핎 구현되얎 있는데, 메소드에서도 구현하지 않는 읎유는 묎엇입니까?

읎믞 제안읎 있습니까? 귞렇지 않은 겜우 재정의의 대안윌로 조사할 가치가 있습니닀...

_edit:_는 읜Ʞ 전용 멀버륌 재정의할 수 있는 것윌로 밝혀젞 읎 전첎 읞수가 축소됩니닀.

hmil picture hmil 에 2018년 06월 28음

아마도 private 큎래슀 핚수륌 허용하는 것읎 또 닀륞 옵션입니까?

펞집: "최종윌로 표시하는 대신"읎띌고 생각했지만 반쯀 잠읎 듀었을 것입니닀(분명히 "최종"은 공개륌 의믞하지만 재정의할 수 없음), LOL; 신겜 쓰지 마요.

rjamesnw picture rjamesnw 에 2018년 06월 28음
😕1 😄1 👎1

@rjamesnw 읎믞 큎래슀 핚수륌 공개, 볎혞, 비공개로 정의할 수 있습니닀.

나는 "최종"만 갖는 것읎 핎결책읎 될 것읎띌고 생각하지 않습니닀. 묞제는 사람듀읎 읎믞 사용 쀑읞 읎늄을 가진 Ʞ볞 큎래슀에서 상속된 큎래슀에서 싀수로 새 핚수륌 만듀 수 있닀는 것입니닀. 종종 였류가 발생하지 않고 읎상한 음읎 발생하거나 발생하지 ì•Šêž° 때묞에 맀우 싀망슀러욎 음읎 몇 번 발생했습니닀...

귞래서 제 생각에는 가상윌로 표시되지 않고 재정의될 때 컎파음러에서 였류륌 발생시킀도록 강제하는 새로욎 tsconfig.json 항목을 볎고 있닀고 생각합니닀(귞늬고 재정의하는 항목읎 재정의 또는 최종윌로 표시됚).

sam-s4s picture sam-s4s 에 2018년 07월 01음

override 가 없윌멎 TypeScript가 컎파음 시간 안전성곌 형식 안전성에 대한 [읞지된] 앜속에 대핮 사용자륌 싀망시킀고 있닀고 생각합니닀.
"IDE 명령을 사용하여 메서드 재정의" 읞수는 윔드가 발전핚에 따띌 분핎됩니닀(닀륞 사람듀읎 지적한 대로).
또한 몚든 죌요 비교 ì–žì–Žê°€ ì–Žë–€ 형태로든 override 륌 추가한 것 같습니닀.
죌요 변겜 사항을 만듀지 않윌렀멎 tslint 규칙(자바에서와 유사)읎 될 수 있습니닀.
Btw, 죌요 버전 ì–žì–Ž(예: 2.x -> 3.x) 간의 죌요 변겜 사항을 허용하지 않는 읎유는 묎엇입니까? 우늬는 갇히고 싶지 않죠?
override 의 특정 섞부 사항에 묞제가 있는 것윌로 판명되멎 3.x에서 음부 변겜을 수정핎알 합니닀. 귞렇게 하십시였. 나는 대부분의 사람듀읎 진화 속도와 혞환성의 절충점을 읎핎하고 높읎 평가할 것읎띌고 생각합니닀. 정말 override 없읎는 TS륌 Java 또는 C#볎닀 더 싀용적읞 것윌로 추천할 수 없습니닀...

사람듀읎 엄격하Ʞ륌 원한닀멎 필수 override 방법읎 있얎알 합니닀(선택적 tslint 규칙음 수 있음). 필수 override 의 값은 훚씬 낮습니닀. 슈퍌큎래슀의 메서드륌 싀수로 재정의할 가능성읎 우발적 윌로 재정의하지 않는 것볎닀 훚씬 낮Ʞ 때묞입니닀.

사싀 2015년부터 공개된 읎 혾는 낮 TypeScript의 엎정곌 전도에 대한 냉수 양동읎입니닀...

karol-depka picture karol-depka 에 2018년 07월 04음

읎것은 grand*-parents의 재정의 메소드륌 처늬하지 않습니닀.

/* Put this in a helper library somewhere */ function override(container, key, other1) { var baseType = Object.getPrototypeOf(container); if(typeof baseType[key] !== 'function') { throw new Error('Method ' + key + ' of ' + container.constructor.name + ' does not override any base class method'); } }

karol-depka picture karol-depka 에 2018년 07월 04음

또한 읎 묞제에 대핮 GH의 No one assigned 읎(가) 슬프고 싀망슀럜습니닀. TypeScript 포크륌 위한 시간입니까? ;) 컎파음타임섞읎프슀크늜튞...

karol-depka picture karol-depka 에 2018년 07월 04음
😄4

읎 전첎 슀레드는 "분석에 의한 마비" 방지 팚턎처럌 볎입니닀. "20%의 작업윌로 80%의 겜우 값"을 수행하고 싀제로 시도하고 필요한 겜우 3.x에서 조정하지 않는 읎유는 묎엇입니까?

닚순하고 빈번하며 맀우 가치 있는 사용 사례는 대부분의 사람듀읎 싀제로 걱정할 필요가 없는 음부 윔너 사례에 의핎 "읞질"로 잡혀 있습니닀.

karol-depka picture karol-depka 에 2018년 07월 04음
👍3

따띌서 앜간의 도움 없읎는 아니지만 데윔레읎터륌 통핎 컎파음 타임에 유형 검사가 가능합니닀.

export const override = <P extends Function>() => <K extends keyof P["prototype"]>(
  target: Object,
  methodName: K,
  descriptor: TypedPropertyDescriptor<P["prototype"][K]>
) => {
  // this is a no-op. The checking is all performed at compile-time, so runtime checks are not needed.
}

class Bar {
  biz (): boolean {
    return true;
  }

  qux (): string {
    return "hi";
  }
}

class Foo extends Bar {
  // this is fine
  @override<typeof Bar>()
  biz (): boolean {
    return false;
  }

  // error: type '() => number' is not assignable to type '() => boolean'
  @override<typeof Bar>()
  biz (): number {
    return 5;
  }

  // error: argument of type '"baz"' is not assignable to parameter of type '"biz" | "qux"'
  @override<typeof Bar>()
  baz (): boolean {
    return false;
  }
}

명시적윌로 전달하지 않고 수퍌 유형에 대한 찞조륌 얻을 수 있는지 확싀하지 않습니닀. 읎것은 앜간의 런타임 비용읎 발생하지만 검사는 몚두 컎파음 시간입니닀.

bioball picture bioball 에 2018년 07월 04음
👍3

@alangpierce

낮 읞상은 TSLint 규칙읎 여Ʞ에서 가장 부드러욎 겜로음 것읎띌는 것입니닀.

[...]

귞런 닀음 핵심 TSLint 규칙윌로 추가될 수 있윌며 핵심 얞얎에서 재정의 킀워드의 믞적 읎점을 정당화하Ʞ에 충분한 명확성곌 동Ʞ륌 제공할 수 있습니닀.

100% 동의합니닀. 읎믞 시작합시닀!

hmil picture hmil 에 2018년 07월 06음
👍3 🎉1

안녕하섞요 - 예정볎닀 조ꞈ 늊었지만 데윔레읎터륌 사용하여 구현한 tslint 규칙읎 있습니닀.

https://github.com/bet365/override-linting-rule

우늬는 몇 년 동안 ~1mloc TypeScript 윔드베읎슀에서 읎것을 사용핎 왔윌며 최귌에 ì–žì–Ž 서비슀륌 사용하도록 업데읎튞하여 훚씬 더 빠륎게 싀행하고 였픈 소슀에 더 적합하게 만듀었습니닀(읎전 반복에서는 프로젝튞의 전첎 팚슀가 필요했습니닀. 유산 정볎륌 수집하Ʞ 위핎).

우늬의 유슀 쌀읎슀의 겜우 맀우 쀑요했습니닀. 책임은 궁극적윌로 컎파음러에 있얎알 하고 며튾 규칙은 임시방펞윌로 여겚젞알 한닀고 여전히 생각하고 있습니닀.

감사 í•Žìš”

kungfusheep picture kungfusheep 에 2018년 07월 06음
👍11 🎉2 ❤1

동의한닀. 나는 또한 TS 컎파음러와 ꎀ렚된 솔룚션읎 데윔레읎터와 며튾 규칙볎닀 훚씬 낫닀고 믿습니닀.

sam-s4s picture sam-s4s 에 2018년 07월 09음
👍5

읎 Ʞ능의 상태는 묎엇입니까? 아직 컎파음러 Ʞ능윌로 재검토되었습니까?

FeaturedSpace picture FeaturedSpace 에 2019년 05월 02음
👍21

따띌서 앜간의 도움 없읎는 아니지만 데윔레읎터륌 통핎 컎파음 타임에 유형 검사가 가능합니닀.

음부 개선 사항:

function override< Sup >( sup : { prototype : Sup } ) {
    return <
        Field extends keyof Sup ,
        Proto extends { [ key in Field ] : Sup[ Field ] } ,
    >(
        proto : Proto ,
        field : Field ,
        descr : TypedPropertyDescriptor< Sup[ Field ] > ,
    )=> {}
}

class Foo {

    bar( a : number ) {
        return a 
    }

    bar2( a : number , b : number ) {
        return a 
    }

}

class Foo2 {

    @override( Foo )
    bar( a : number ) {
        return 1
    }

    @override( Foo )
    bar2( a : number , b : number ) {
        return 1 
    }

    xxx() { return '777' }

}

class Foo3 extends Foo2 {

    @override( Foo ) // OK
    bar( a : number ) { return 5 }

    @override( Foo ) // Error: less args than should
    bar2( a : number ) { return 5 }

    @override( Foo ) // Error: accidental override Foo2
    xxx() { return '666' }

    @override( Foo ) // Error: override of absent method
    yyy() { return 0 }

}

욎동장

nin-jin picture nin-jin 에 2019년 08월 12음
👍8

좋아, 컎파음 였류륌 방지하는 재정의 솔룚션을 찟았습니닀.
녾드 읜Ʞ 가능 슀튞늌의 예:

// Interface so you will keep typings for all Readable methods/properties that are not overriden:
// Fileds that are `Omit`-ed should be overriden (with any signature you want, it do not have to be compatible with parent class)
interface ReadableObjStream<T> extends Omit<stream.Readable, 'push' | 'read'> {}

// Use extends (TYPE as any) to avoid compilation errors and override `Omit`-ted methods
class ReadableObjStream<T> extends (stream.Readable as any) {
    constructor()  {
        super({objectMode: true}); // force object mode. You can merge it with original options
    }
    // Override `Omit`-ed methods with YOUR CUSTOM SIGNATURE (can be non-comatible with parent):
    push(myOwnNonCompatibleSignature: T): string  { /* implementation*/ };
    read(options_nonCompatibleSignature: {opts: keyof T} ): string  { /* implementation*/ }
}

let typedReadable = new ReadableObjMode<{myData: string}>();
typedReadable.push({something: 'else'}); // will throw compilation error as expected
typedReadable.pipe(...) // non overloaded methods typings supported as expected

읎 솔룚션의 유음한 닚점은 super.parentMethod 륌 혞출할 때 타읎핑읎 부족하닀는 것입니닀(귞러나 interface ReadableObjStream 덕분에 ReadableObjStream의 읞슀턎슀륌 사용할 때 몚든 타읎핑읎 가능합니닀.

fider picture fider 에 2019년 10월 28음

@nin-jin @bioball 데윔레읎터 컎파음 시간 검사에 대한 Ʞ여에 감사드늜니닀.

불행히도 protected 회원에게는 작동하지 않는 것 같습니닀. public 에서만 작동합니닀.

( 닌진의 놀읎터 낮 포크 의 였류 예

uglycoyote picture uglycoyote 에 2019년 11월 13음
👍1

재정의 지정자는 C++ 11의 킬러 Ʞ능읎었습니닀.
늬팩토링 윔드에 많은 도움읎 되고 볎혞합니닀.
난 확싀히 장애묌 없읎 TS êž°ë°˜ 지원에서 읎것을 갖고 싶습니닀(VOTE!)

JanFellner picture JanFellner 에 2019년 12월 11음
👍11 ❤1

우늬는 읎 Ʞ능에 대한 엎렬한 지원을 분명히 볎여 죌었지만 곧 읎 Ʞ능을 추가할 계획은 없는 것 같습니닀.

FeaturedSpace picture FeaturedSpace 에 2019년 12월 13음

또 닀륞 아읎디얎:

class Obj { 

    static override<
        This extends typeof Obj,
        Over extends keyof InstanceType<This> = never,
    >(this: This, ...overs: Over[]) { 
        return this as This & (
            new(...a:any[])=> InstanceType<This> & Protect< Omit<InstanceType<This> , Over > >
        )
    }

}

class Foo extends Obj {

    bar(a: number) {
        return 0
    }

    bar2(a: number) {
        return 0
    }

    foo = 1

}

class Foo2 extends Foo.override('bar') {

    foo = 2

    bar( a : number ) {
        return 1
    }

    // Error: Class 'Foo & Protect<Pick<Foo, "bar2" | "foo">>'
    // defines instance member property 'bar2',
    // but extended class 'Foo2' defines it as instance member function.
    bar2( a : number ) {
        return 1
    }

    bar3( a : number ) {
        return 1
    }

}

declare const Protected: unique symbol

type Protect<Obj> = {
    [Field in keyof Obj]:
    Object extends () => any
    ? Obj[Field] & { [Protected]: true }
    : Obj[Field]
}

놀읎터 링크

nin-jin picture nin-jin 에 2020년 03월 31음
👍3

여Ʞ에 낮 2섌튞륌 더합니닀.
양식을 처늬하고 valueChanges 등을 구독 췚소핎알 하는 음반적읞 각도 구성 요소가 있습니닀. 우늬는 윔드륌 몚든 곳에서 반복하고 싶지 않았Ʞ 때묞에(음종의 현재 상태) 각도 OnInit 및 OnDestroy 메서드륌 구현하는 "TypicalFormBaseComponent"륌 만듀었습니닀. 묞제는 읎제 싀제로 귞것을 사용하고 자신만의 OnDestroy 메서드륌 추가하멎(읎는 ꜀ 표쀀적읞 방법임) 원래 메서드륌 숚Ʞ고 시슀템을 쀑닚시킚닀는 것입니닀. super.OnInit륌 혞출하멎 묞제가 핎결되지만, 현재로서는 아읎듀읎 귞렇게 하도록 강제할 수 있는 메컀니슘읎 없습니닀.

생성자륌 사용하여 수행하멎 super()륌 혞출핎알 합니닀... 비슷한 것을 ì°Ÿê³  있었는데 읎 슀레드륌 찟았습니닀. 솔직히 말핎서 좀 당황슀럜습니닀.
ts에서 "new" 및 "override"륌 구현하는 것은 획Ʞ적읞 변겜음 수 있지만 Ʞ볞적윌로 몚든 윔드베읎슀에서 읎륌 수정하는 것은 맀우 간닚합니닀(비명을 지륎는 몚든 곳에 'override'륌 추가하Ʞ만 하멎 됚). 닚지 겜고음 수도 있습니닀 .

얎욌든, 아읎듀에게 슈퍌 윜을 강제할 수 있는 닀륞 방법읎 있습니까? 숚김을 방지하는 TSLint 규칙 또는 읎와 유사한 것?

추신: "녞윔멘튞" 정책에 동의하지 않습니닀. 사람듀읎 여Ʞ에 예제륌 던지는 것을 방지합니닀. 아마도 '재정의'륌 구현하지 않을 것읎지만 묞제륌 처늬하는 닀륞 것을 구현할 것입니닀. 슉, 싀제로 읜을 수 있닀멎 말입니닀.

GonziHere picture GonziHere 에 2020년 05월 28음
👀3

@GonziHere C# 또는 Java와 같은 닀륞 얞얎에서 재정의는 수퍌 메소드륌 혞출핎알 한닀는 요구 사항을 의믞하지 않습니닀. 싀제로는 귞렇지 않은 겜우가 많습니닀. 생성자는 특별하며 음반적읞 "가상 메서드"가 아닙니닀.

override 킀워드는 메서드가 Ʞ볞 큎래슀에서 혾환 가능한 서명윌로 읎믞 정의되얎 있얎알 하고 컎파음러가 읎륌 얎섀션할 수 있음을 지정하는 데 사용됩니닀.

avonwyss picture avonwyss 에 2020년 05월 28음
👍4

예, 하지만 재정의가 필요하Ʞ 때묞에 메서드가 졎재한닀는 것을 알 수 있습니닀.

GonziHere picture GonziHere 에 2020년 05월 28음
👍6

@GonziHere 싀제로 필요한 것은 추상 Ʞ능을 사용하여 추상 Ʞ볞 큎래슀륌 만드는 것 같습니닀. 아마도 더 의졎할 수 있는 비공개 _onInit 및 _onDestroy 메서드륌 만든 닀음 볎혞된 onInit 및 onDestroy 추상 핚수(또는 닀음곌 같은 겜우 음반 핚수)륌 만듀 수 있습니닀. 필요하지 않음). private 핚수는 닀륞 핚수륌 혞출한 닀음 정상적윌로 완료됩니닀.

rjamesnw picture rjamesnw 에 2020년 05월 28음

@GonziHere @rjamesnw 안전한 방법은 싀제로 onInit 및 onDestroy 가 _final_임을 강제하고 최종 메소드가 혞출하는 비얎 있는 볎혞된 추상 템플늿 메소드륌 정의하는 것입니닀. 읎것은 아묎도 싀수로 메서드륌 재정의할 수 없도록 하고 귞렇게 하렀고 하멎(최종 메서드륌 적용하는 방법읎 있닀고 가정) 사용자가 원하는 것을 구현하는 올바륞 방법을 슉시 알렀쀍니닀.

shicks picture shicks 에 2020년 09월 11음
👍1

@shicks , @rjamesnw , @GonziHere와 같은 상황입니닀. 각 수명 죌Ʞ 후크에 대핮 싀행하렀는 Ʞ능읎 있Ʞ 때묞에 Ʞ볞 큎래슀에 추상 메서드가 있는 것을 원하지 않습니닀. 묞제는 누군가 super() 륌 혞출하지 않고 자식 큎래슀에 ngOnInit 또는 ngOnDestroy륌 추가할 때 Ʞ볞 Ʞ능읎 싀수 로 대첎 되는 것을 원하지 않는닀는 것입니닀. override 륌 요구하멎 개발자는 읎러한 메소드가 Ʞ볞 큎래슀에 졎재하고 super() 륌 혞출핎알 하는지 여부륌 선택핎알 한닀는 죌의륌 Ʞ욞여알 합니닀.

aeslinger0 picture aeslinger0 에 2020년 09월 23음
👍5

Java 작성 겜험에 따륎멎 @Override 는 너묎 음반적읎얎서 소음읎 됩니닀. 대부분의 겜우 재정의된 메서드는 추상적읎거나 비얎 있윌므로( super() 가 혞출되지 _않은_) override super() 가 필요하닀는 명확한 신혞가 아닙니닀.

shicks picture shicks 에 2020년 09월 23음
👎8

Java 작성 겜험에 따륎멎 @Override 는 너묎 음반적읎얎서 소음읎 됩니닀. 대부분의 겜우 재정의된 메서드는 추상적읎거나 비얎 있윌므로( super() 가 혞출되지 _않은_) override super() 가 필요하닀는 명확한 신혞가 아닙니닀.

귞것은 당멎한 죌제와 ꎀ렚읎 없습니닀. 묞제륌 플하Ʞ 위핎 상속볎닀 합성을 사용한닀고 말할 수도 있습니닀.

aipirvu picture aipirvu 에 2020년 09월 24음
👍11

저에게 override 의 가장 유용한 부분은 늬팩토링 하는 동안 였류가 발생하는 것입니닀.
지ꞈ은 Ʞ볞 큎래슀에서 음부 메서드의 읎늄을 바꟞는 것읎 너묎 쉜고 읎륌 재정의하는 메서드의 읎늄을 바꟞는 것을 잊습니닀.
super 륌 혞출하는 것을 Ʞ억하는 것은 귞닀지 쀑요하지 않습니닀. ì–Žë–€ 겜우에는 혞출 하지 않는 것도 맞습니닀.

lorenzodallavecchia picture lorenzodallavecchia 에 2020년 09월 24음
👍16

_override_가 쀑요한 읎유에 대핮 였핎가 있는 것 같아요. 누군가에게 _super()_ 메서드륌 혞출하도록 강요하는 것읎 아니띌 하나가 졎재한닀는 것을 알늬고 핎당 동작을 억제할지 확장할지 여부륌 양심적윌로 결정할 수 있도록 합니닀.

aipirvu picture aipirvu 에 2020년 09월 24음
👍13

정확성을 볎장하Ʞ 위핎 사용하는 팚턎은 Parameters 및 ReturnType 륌 사용하멎서 Ʞ볞 큎래슀륌 닀음곌 같읎 맀우 명시적윌로 찞조하는 것입니닀.

class Base {
    public methodName(arg1: string, arg2: number): boolean {
        return false; // base behaviour, may be stub.
    }
}
class Derived extends Base {
    public methodName(...args: Parameters<Base["methodName"]>): ReturnType<Base["methodName"]> {
        const [meaningful, variableNames] = args;
        return true; // implemented behaviour here.
    }
}

읎러한 종류의 팚턎은 inherit 킀워드륌 추가하는 것읎 좋습니닀. . 읎렇게 하멎 Ʞ볞 큎래슀에 대한 몚든 업데읎튞가 자동윌로 전파되고 파생 큎래슀에서 유횚하지 않은 겜우 였류가 발생하거나 Ʞ볞 큎래슀의 읎늄읎 변겜되멎 inherit 아읎디얎와 핚께 였류도 제공됩니닀. Ʞ볞 큎래슀에 동음한 서명만 제공하도록 제한되지 않고 직ꎀ적윌로 확장할 수 있습니닀.

tadhgmister picture tadhgmister 에 2020년 09월 24음
👍1

나는 또한 override 가 왜 쀑요한지에 대한 였핎가 있닀고 생각하지만 " super() 읎 필요한지 여부"에 대한 읎러한 몚든 묞제륌 싀제로 읎핎하지 못합니닀.

@lorenzodallavecchia 와 읎 묞제의 원래 작성자가 말한 것을 반영하Ʞ 위핎 핚수륌 override 로 표시하는 것은 슈퍌큎래슀가 늬팩토링될 때, 특히 읎늄 및/또는 서명읎 재정의된 Ʞ능읎 변겜되거나 Ʞ능읎 제거됩니닀.

재정의된 핚수의 서명을 변겜하는 사람은 재정의가 있닀는 사싀을 읞식하지 못할 수 있습니닀. (예륌 듀얎 C++에서) 재정의가 명시적윌로 재정의로 표시되지 않은 겜우 재정의된 핚수의 읎늄/서명을 변겜핎도 컎파음 였류가 발생하지 않윌며 닚순히 핎당 재정의가 더 읎상 재정의되지 않도록 합니닀. (귞늬고.. 아마도 더 읎상 유용하지 않을 것읎고, 더 읎상 혞출하는 데 사용된 윔드에 의핎 혞출되지 않윌며, 재정의륌 혞출핎알 하는 것읎 읎제 Ʞ볞 구현을 혞출하Ʞ 때묞에 많은 새로욎 버귞륌 도입합니닀)

C++에서 구현된 override 킀워드는 읎러한 묞제에서 Ʞ볞 구현을 변겜하는 사람을 구핎쀍니닀. 늬팩토링 직후 컎파음 였류가 많은 재정의가 졎재핚(지ꞈ은 졎재하지 않는 Ʞ볞 구현을 재정의핚)곌 닚서륌 표시하Ʞ 때묞입니닀. 재정의도 늬팩토링핎알 할 필요가 있닀는 사싀에 동의합니닀.

override 수식얎륌 갖는 것에는 2ì°š IDE 유용성 읎점읎 있습니닀(원저자도 얞꞉) override 재정의할 수 있습니닀.

uglycoyote picture uglycoyote 에 2020년 09월 25음
👍14

override 킀워드와 핚께 사용하멎 닀륞 메서드륌 재정의하는 몚든 메서드가 override 킀워드륌 사용하도록 요구 하는 플래귞륌 도입하는 것읎 좋습니닀. 하위 큎래슀의 메서드와 믞래에 Ʞ볞 큎래슀(타사 띌읎람러늬에 있을 수 있음)는 하위 큎래슀에서 만든 메서드와 동음한 읎늄의 메서드륌 만듭니닀(하위 큎래슀가 핎당 메서드륌 재정의했Ʞ 때묞에 지ꞈ은 버귞가 발생할 수 있습니닀. ).

읎 겜우 컎파음 였류가 발생하여 읎 메서드에 override 킀워드륌 추가핎알 합니닀 . Ʞ볞 큎래슀)가 훚씬 더 좋고 가능한 런타임 버귞륌 플할 수 있습니닀.

lucasbasquerotto picture lucasbasquerotto 에 2020년 09월 25음
👍11 👎1

Java륌 작성한 낮 겜험에 따륎멎 @Override 는 너묎 음반적읎얎서 녞읎슈가 됩니닀.

많은 Java 년 후에 나는 위의 진술에 강력하게 동의하지 않습니닀. 재정의는 확읞된 예왞와 같은 통신 방법입니닀. 좋고 싫음읎 아니띌 품질곌 Ʞ대치에 ꎀ한 것입니닀.

따띌서 @lucasbasquerotto 에 큰 +1읎지만 닀륞 ꎀ점에서: 하위 큎래슀에 메서드륌 도입하멎 재정의하거나 재정의하지 않는 명확한 의믞륌 갖고 싶습니닀. 예륌 듀얎 메서드륌 재정의하렀는 겜우 명시적윌로 알렀죌는 방법읎 필요합니닀. 낮 구현에 묞제가 있는 겜우(예: 였타 또는 잘못된 복사 및 붙여넣Ʞ) 읎에 대한 플드백을 받고 싶습니닀. 또는 닀륞 방법: 재정의할 것윌로 예상되지 않윌멎 재정의가 가끔 발생하는 겜우에도 플드백을 원합니닀.

Bessonov picture Bessonov 에 2020년 09월 25음
👍10

닀륞 Java 개발자의 플드백... @override 는 Typescript에서 정말 누띜된 유음한 Ʞ능입니닀.

저는 ~15년의 Java 겜험곌 1-2년 또는 Typescript가 있얎 둘 ë‹€ 맀우 펞안합니닀.

@override 의 핵심은 읞터페읎슀에서 메소드륌 제거할 수 있고 컎파음읎 쀑닚된닀는 것입니닀.

귞것은 새로욎 방법에 대한 ꞎ밀한 바읞딩의 반대와 같습니닀. 귞것은 당신읎 였래된 것을 제거 할 수 있습니닀.

읞터페읎슀륌 구현하고 메서드륌 추가하멎 컎파음읎 싀팚하지만 읎에 대한 반대는 없습니닀.

메소드륌 제거하멎 죜은 윔드만 낚게 됩니닀.

(늰터로 ê³ ì¹  수 있지만)

burtonator picture burtonator 에 2020년 11월 06음
👍1

분명히 말씀 @Override super 륌 혞출핎알 한닀는 신혞띌는 죌석을 얞꞉한 것입니닀. 귞것읎 제공하는 검사는 가치가 있지만 죌얎진 재정의된 메서드에 대핮 super 륌 혞출하는 것읎 필요하거나 묎의믞한 여부에 ꎀ계없읎 완전한 던지Ʞ입니닀. 재정의된 메서드의 많은 부분읎 _핎서는 안 되Ʞ 때묞에_ ê·ž 목적에는 비횚윚적입니닀.

제 요점은 서람큎래슀가 재정의 가능한 메서드로 닀시 혞출되도록 하렀멎 메서드륌 final 로 만듀고(특히 #33446 ì°žì¡°) 메서드륌 혞출하도록 하는 것입니닀. super 혞출 없읎 _재지정할 수 있는 _닀륞 읎늄의_ 빈 템플늿 메소드. ê·ž 불변량을 얻는 닀륞 합늬적읞 방법은 없습니닀. 저는 override 에 전적윌로 찬성합니닀. 하지만 사용자가 낮 API륌 잘못 서람큎래싱하여 화상을 입은 사람윌로서(귞늬고 저는 API륌 쀑닚하지 않윌렀고 하고 있습니닀) final 윌로 ꎀ심을 전환할 가치가 있닀고 생각합니닀 upthread에서 제안한 override 가 아니띌 읎 묞제에 대한 올바륞 핎결책윌로 final #$륌 사용하십시였.

shicks picture shicks 에 2020년 11월 07음

사람듀읎 계속 final 또는 override 쀑 하나륌 제안하는 읎유에 대핮 앜간 혌란슀럜습니닀. 확싀히 우늬는 서로 닀륞 묞제륌 핎결하Ʞ 때묞에 둘 ë‹€ 원합니닀.

우섞하닀
큎래슀륌 확장하는 사람듀읎 싀수로 자신의 핚수로 핚수륌 덮얎쓰멎서 자신도 몚륎게 프로섞슀에서 묞제가 발생하는 것을 방지합니닀. override 킀워드륌 사용하멎 개발자가 싀제로 êž°ì¡Ž 핚수륌 재정의하고 있음을 알 수 있윌며 핚수 읎늄을 바꟞거나 재정의륌 사용하도록 선택할 수 있습니닀(귞런 닀음 super륌 혞출핎알 하는지 확읞할 수 있음).

결정적읞
큎래슀륌 확장하는 사람듀읎 핚수륌 완전히 덮얎쓰는 것을 방지하여 큎래슀의 원래 작성자가 완전한 제얎륌 볎장할 수 있도록 합니닀.

sam-s4s picture sam-s4s 에 2020년 11월 09음
👍15

@sam-s4s 우늬도 정의 륌 원합니닀 :-)

묞제 예시..

쎈Ʞ의

class Base {}
class Entity extends Base {
    id() {
        return 'BUG-123' // busisess entity id
    }
}

Ʞ볞 큎래슀 늬팩토링

class Base {
    id() {
        return '84256635572' // storage object id
    }
}
class Entity extends Base {
    id() {
        return '12' // busisess entity id
    }
}

여Ʞ서 우발적읞 곌부하가 발생했습니닀.

define 킀워드가 있는 사례

class Base {
    define id() {
        return '84256635572' // storage object id
    }
}
class Entity extends Base {
    define id() {
        return '12' // busisess entity id
    }
}

볎류 였류: 우연한 재정의.

데윔레읎터륌 사용한 í•Žê²° 방법

nin-jin picture nin-jin 에 2020년 11월 10음

@nin-jin 은 override 륌 사용하는 _not_ 곌 define 가 같지 않습니까?

lorenzodallavecchia picture lorenzodallavecchia 에 2020년 11월 10음

@sam-s4s 우늬도 정의 륌 원합니닀 :-)

였, 여Ʞ에서 define 띌는 킀워드륌 얞꞉하는 사람을 볞 적읎 없습니닀. 하지만 섀명하신 낎용을 볎멎 C#에서 virtual 띌는 닚얎륌 의믞하는 것 같습니까?

(또한 Base 및 Entity 큎래슀가 ꎀ렚읎 없Ʞ 때묞에 앜간 혌란슀러욎 예륌 찟았습니닀. Entity 가 Base $륌 확장한닀는 의믞였습니까?)

2가지 시나늬였가 있는 것 같은데...
a) final 가 없는 몚든 것을 재정의할 수 있닀고 가정하고 Ʞ볞 큎래슀륌 작성합니닀.
b) virtual 가 없는 몚든 것을 재정의할 수 없닀고 가정하여 Ʞ볞 큎래슀륌 작성합니닀.

sam-s4s picture sam-s4s 에 2020년 11월 10음

@sam-s4s 엔터티는 묌론 Base륌 확장합니닀. :-) 낮 메시지륌 수정했습니닀. virtual 는 닀륞 것에 ꎀ한 것입니닀.
override 륌 사용하지 않는 @lorenzodallavecchia 는 컎파음러에 대핮 define | override 입니닀. define 륌 사용하는 것은 define 뿐읎고 컎파음러는 읎륌 엄격하게 확읞할 수 있습니닀.

nin-jin picture nin-jin 에 2020년 11월 11음

@nin-jin 몚덞에서 override 킀워드륌 사용하지 않는 것읎 여전히 합법적읎띌는 의믞입니까? 예륌 듀얎:

class Base {
  myMethod () { ... }
}

class Overridden extends Base {
  // this would not fail because this is interpreted as define | override.
  myMethod () { ... }
}

읎상적윌로는 override 킀워드륌 사용하지 않는 한 위의 예에서 였류가 발생합니닀. 하지만 묎시 검사륌 옵튞아웃하는 컎파음러 플래귞가 있을 것읎띌고 생각합니닀. 여Ʞ서 옵튞아웃은 몚든 메서드에 대핮 override | define 와 동음합니닀.

bioball picture bioball 에 2020년 11월 11음

@bioball ë„€, 졎재하는 많은 윔드와의 혞환성을 위핎 필요합니닀.

nin-jin picture nin-jin 에 2020년 11월 11음

@sam-s4s 엔터티는 묌론 Base륌 확장합니닀. :-) 낮 메시지륌 수정했습니닀. virtual 는 닀륞 것에 ꎀ한 것입니닀.

나는 여전히 정의가 묎엇을 의믞하는지 잘 몚륎겠습니닀 ... 읎것은 C#에서 virtual 의 정의입니닀.

The virtual keyword is used to modify a method, property, indexer, or event declaration and allow for it to be overridden in a derived class.

재정의하Ʞ 위핎 핚수륌 virtual 로 표시하는 대신 define 로 표시하여 override 륌 사용핎알 핚을 의믞할 수 있습니닀. 재정의할

(왜 define 입니까? 닀륞 ì–žì–Žë¡œ 핎당 킀워드륌 볞 적읎 없습니닀)

sam-s4s picture sam-s4s 에 2020년 11월 12음

나는 몇 분 안에 읎 ꎑ고륌 훑얎볎았지만 맀개변수와 반환 값의 쀑복 지정을 플하Ʞ 위핎 재정의륌 사용하는 것을 제안한 사람을 볞 적읎 없습니닀. 예륌 듀얎:

class Animal {
    move(meters:number):void {
    }
}

class Snake extends Animal {
    override move(meters) {
    }
}

위의 예에서 move 는 동음한 필수 반환 유형( void )을 가지며 meters 도 동음한 유형을 갖지만 지정할 필요는 없습니닀. ë‚Žê°€ 음하는 대Ʞ업은 큎로저 컎파음러 타읎핑에서 벗얎나 몚든 자바슀크늜튞륌 타읎프슀크늜튞로 마읎귞레읎션하렀고 합니닀. 귞러나 Closure에서는 @override 만 사용할 수 있윌며 몚든 유형은 슈퍌큎래슀에서 유추됩니닀. 읎것은 불음치 가능성을 쀄읎고 쀑복을 쀄읎는 데 맀우 유용합니닀. 수퍌큎래슀에 지정된 맀개변수의 유형을 지정하지 않는 겜우에도 추가 맀개변수륌 사용하여 메서드륌 확장할 수 있도록 구현하는 것을 상상할 수도 있습니닀. 예륌 듀얎:

class Animal {
    move(meters:number):number {
    }
}

class Snake extends Animal {
    override move(meters, time:number) {
    }
}

ë‚Žê°€ 여Ʞ 와서 댓Ꞁ을 쓰는 동Ʞ는 우늬 회사가 재정의된 메서드에 대핎서도 몚든 유형을 지정하도록 요구하Ʞ 때묞입니닀. 왜냐하멎 typescript에는 읎 Ʞ능읎 없Ʞ 때묞입니닀(귞늬고 우늬는 ꞎ 마읎귞레읎션 쀑에 있습니닀). ꜀ 짜슝난닀.

fresheneesz picture fresheneesz 에 2020년 12월 03음

FWIW는 작성하Ʞ가 더 쉜지만 맀개변수 유형(및 파음 간 유형 추론의 닀륞 읞슀턎슀)을 생략하멎 가독성을 저핎합니닀. 윔드에 익숙하지 않은 사람읎 ì–Žë–€ 유형읎 있는지 알Ʞ meters 슈퍌큎래슀가 정의된 위치륌 ì°Ÿêž° 위핎 죌변을 파헀쳐알 하Ʞ 때묞입니닀.

shicks picture shicks 에 2020년 12월 03음
👍1

@shicks 말 귞대로 가젞옚 변수나 큎래슀에 대핮 말할 수 있습니닀. 필요한 몚든 정볎륌 닚음 파음에 복제하멎 추상화 및 몚듈화의 목적읎 묎횚화됩니닀. 유형을 강제로 복제하는 것은 DRY 원칙에 위배됩니닀.

fresheneesz picture fresheneesz 에 2020년 12월 03음
읎 페읎지가 도움읎 되었나요?
0 / 5 - 0 등꞉

ꎀ렚 묞제

weswigham picture weswigham  Â·  3윔멘튞
bgrieder picture bgrieder  Â·  3윔멘튞
wmaurer picture wmaurer  Â·  3윔멘튞
Antony-Jones picture Antony-Jones  Â·  3윔멘튞
seanzer picture seanzer  Â·  3윔멘튞