규격 건의서

묘사

66호 간선 - 건설 중
베이비론은 해석decorated generator functions에 문제가 존재하기 때문에 현재의 장식기 규범은 너무 느슨하고 복잡한 것 같다.
이런 게 있긴 한데 정말 좋아요.

@f?f:f1

장식사에게 있어서 흔히 볼 수 있는 것이기 때문에 표준적인 용례가 너무 많다

@decorate(options)
@decorate
class Foo {
...
}

한 사람을 생각하면 지금 할 수 없어요.

class Foo
{
    @decorate
    * gen() { yield 1; }
}

현재 규범은 LeftHandSideExpression에 기초를 두고 있기 때문에 예를 들어 바빌론 해석기가 이를

BinaryExpression
    left: 'decorate'
    operator: '*'
    right: 'gen()'

장식기를 CallExpressionS와 MemberExpressionS의 특수 변형으로 제한하는 방법은 아마도 가장 자주 사용하는 장식기 형식일 것이다.그것만 있으면 바빌론 해석기가 생성기 방법의 장식을 지원하기 위해 복구될 수 있다.

제의하다

MemberReference[수익률]:
  명칭[생산량] 식별
  MemberReference[? 수익률][표현식[In,? 수익률]
  MemberReference[? 수익률].명칭[생산량] 식별
DecoratorCallExpression[생산량]:
  MemberReference[? Yield] 매개변수 [? Yield]
  DecoratorCallExpression[? Yield] 매개 변수 [? Yield]
  DecoratorCallExpression[?생산량].명칭[생산량] 식별
  DecoratorCallExpression[Yield][Expression[In,Yield]]
장식사[굴복]:
  @DecoratorExpression[생산량]
DecoratorExpression[Yield]:
  DecoratorCallExpression[생산량]
  멤버 참조[?수익률]
이상은 우리를 허락할 것이다

@decorators[Symbol](options)
@decorator(options)
@lib.decorator
class Foo
{
    // not sure about this one, production rule wise that is, though
    @broker.getInstance(IFancyDecorators).decorate()
    * gen() {}
}

잠깐만요.

이론적 기초

LeftHandSideExpression의 현재 규범이 너무 느슨해서 사용자 장식 생성기 방법을 막을 수 있습니다. 위에서 인용한 바빌론 문제를 참고하십시오.
Angular2에서 TypeScript를 사용하는 경우 사용 가능한 문서에는 위에서 설명한 두 가지 용례만 표시됩니다.파이톤과 프레임에서도 상술한 두 가지 용례보다 더 복잡한 것을 볼 수 없습니다.자바나 유사한 언어의 주석도 마찬가지다. 이 두 가지 용례는 이미 이 언어의 고정적인 습관이 되었고, 이것은 실제로도 파이톤에 적용된다.
@lukescott, @wycats, @loganfsmyth, @jayphelps, @Download 당신은 이미 #23에서 이 문제를 토론한 적이 있습니다. 저는 우리가 이 문제를 더욱 토론해야 한다고 생각합니다.

토론 #1

@SilkEntry 저는 이 변화를 전적으로 지지합니다. (저는 이 일에 대해 아무런 발언권이 없습니다. 기억하세요:) 이것은 제가 생각하는 가장 우아한'괄호 문제'를 해결하는 방법을 대표합니다.나는 내가 그 문법 묘사를 읽을 때 항상 어려움이 있다는 것을 인정해야 한다.그런데 괄호 문자(와 )가 어딘가에 나타났으면 좋겠어요?이것은 반드시 ES규범 중의 어느 곳에 있어야 한다. 왜냐하면 구조 함수 호출에서 괄호도 선택할 수 있기 때문이다. 그렇지?
어쨌든, 만약 문법이 내가 그것을 의미한다고 생각한다면, 나는 그것이 left hand side expression 보다 훨씬 낫다는 것에 전적으로 동의한다.
나는 이 제의가 사실상 #65의 제의와 결합될 수 있다고 생각한다. 그렇지 않니?인테리어 과정을 막을 수 있다는 것 자체가 가치가 있다고 생각했기 때문이다.

토론 #2

@Download Call Expression이 바로 당신이 원하는 것입니다.#65 또는 #62와 조합할 수 있습니다.
이것은 지역 사회 프로젝트이기 때문에 우리는 적어도 결과가 어떻든지 간에 제기하려고 시도할 수 있다.

토론 #셋

그래서 나는 이 논점들이 포착되지 않았다고 가정한다.이것은 단지 제한 문법일 뿐입니다. 생성기에 대한 수식을 허용합니다. 그렇습니까?이것은 일리가 있는 것이다.
논쟁이 결국 잡히면, 나는 이렇게 하지 말라고 건의한다.다만 마지막으로 들어온 매개 변수가 1:1과 일치해야 하기 때문이다.이것은 나로 하여금 LeftHandSideExpression가 정확한 해결 방안이라고 믿게 한다.발전기를 지원하기 위해 제한을 가해야 한다는 것에 동의합니다.
따라서 내가 보기에 표현식의 결과는 장식자로 여겨져야 한다. LeftHandSideExpression 와 같다.decorator duck 유형 문제는 별도로 처리해야 합니다.

토론 #4

@lukescott가 매개 변수화 장식기에 전달하는 매개 변수는

DecoratorCallExpression [Yield] :
  MemberReference [?Yield] Arguments [?Yield]
  DecoratorCallExpression [?Yield] Arguments [?Yield]
...

당신이 언급한 또 다른 문제는 실현/운행할 때 특정한 것으로 문법의 일부분에 속하지 않습니다.그것은 장식기를 사용할 때 사용할 수 있는 사용 가능한 기호만 처리합니다.

토론 #5

새로운 규범안을 고려하면 LeftHandside 표현식이 될 것이다.해상도 변환기에 고장이 난 것 같습니다. 이 경우 바벨입니다.

토론 #6

이 상태를 유지할 필요가 없습니다.바벨이 원하는 대로 일을 하도록 설득해야 한다.