적분제는 주관적인 것 같다

묘사

호환성표에서 특징점 값을 지정한다.'미소한 차이(1점)'와'랜드마크 기능(8점)'등이지만 이런 평점은 주관적인 것으로 보인다.무엇이 하나의 기능을 더욱 중요하거나 더 중요하지 않게 합니까?
e. 예를 들어 약속은 유용하지만 비공식적으로 표준화되어 ES5에서 실시되었다.내가 보기에 이것은 이 기능을 그다지 중요하지 않게 할 것이다.그러나 그것은 '지표' 라는 라벨이 붙어 있었다.비록 꼬리 호출은 새로운 알고리즘과 프로그래밍 스타일을 지원하지만, 꼬리 호출은 단지 '중요한 것' 일 뿐이다. (확장과 계산 대상의 문자 키와 같은 문법 설탕만큼 돌파적인 것은 분명하지 않다.)
나는 네가 이런 특성들을 다시 평가하도록 설득하고 싶지 않다.내가 지적하고자 하는 것은'의미'는 하나의 관점 문제이다.등급 평가는 사실이 아니어서 통계표에 적합하지 않게 보인다.
기능에 대해 등급을 매기는 것은 호환성과 무관한 것 같다. 등급이 실현될 수 있는 어려움과 일정한 관련성이 없으면.나는 이 등급들을 삭제할 것을 건의한다.

토론 #1

의 약속은 ES5에 존재하지 않는다. 약속/A+로 비공식적으로 표준화되었지만 ES6가 언어의 일부가 될 때까지.그것이 이정표적 의미를 가진 이유는 ES5 방법으로 실현할 수 있기 때문에 그 어떤 방식으로도 그 중요성을 낮추지 않기 때문이다.
물론 중요성은 의견의 문제이다. 그러나 나는 왜 단지 책상 위에 있기 때문에 사람들이 아무런 의견도 기대하지 않는지 확실하지 않다.현저성은 가중 완성 비율에 쓰인다.너는 마음대로 그것을 소홀히 할 수 있다. 단지 네가 관심을 가지는 개별 기능을 보기만 하면 된다.

토론 #2

It's landmark because it's a critical language primitive

Map과 WeakMap은 절대적으로 관건적인 언어의 원어이지만 significance: 'small' Symbol으로 medium으로 표기되어 있다.몇몇 입장을 재고하는 것은 일리가 있다.

토론 #셋

공평합니다.이 문제는 의미를 완전히 제거한 것 같다. 우리는 새로운 토론을 열어 구체적인 수정을 해야 한다.

토론 #4

@ljharb:

Promises were not in ES5 whatsoever

분명히 말하자면, 내 말은 ES5를 사용하여 약속을 실현하는 것이 가능하다는 것이다.당시와 현재의 유일한 차이는 의존성을 줄이는 것일 수도 있다.

The significance is used to weight completion percentages.

알겠습니다.이런 상황에서 나는 이 통계 데이터가'완성'권중의 사용으로서 주관성을 바탕으로 하는 것이라고 의심한다.

토론 #5

은 우리가 계산한 규범의 각 부분을 제외하고는 기능 목록 자체에도 주관성이 필요하다. 이것은 매우 유용하지 않다.이 일에 있어서 편견을 갖지 않는 방법은 아예 없다.

토론 #6

은 특정한 상황을 해결하기 위해 WeakMap이 small으로 표시된 이유는 WeakSet의 기능'유형'과 같기 때문이다. 즉, small - small(0.25)+small(0.25)=medium(0.5)이다.
나는 적당한 꼬리 호출을 large으로 늘리고 싶다. 이 특정 기능은 양방향으로 미끄러질 수 있다.

토론 #7

은 단어를 잘못 썼을지도 모른다.'부차적인','유용한','중요한','상징적인'은 마치 프로그래머가 특정한 기능에 대한 개인적인 선호처럼 들린다.보아하니 네가 진정으로 묘사하고자 하는 것은'규범의 전체적인 완성 상황에 비해 기능의 크기'이다.
만약 그렇다면, 당신은 서로 다른 프레젠테이션 원고를 사용하고 이 기능 집합을 재평가하는 것을 고려할 수 있습니다.또는 (더 좋을 수도 있음) '%complete' 기능을 삭제합니다. 너무 어려워서/계산할 수 없을 것 같습니다. (실제로는 그렇게 유용하지 않습니다.)

토론 #8

이것은 매우 유용한 것이다. 실현자(즉 브라우저 개발자)는 이 숫자를 자주 사용하여 그들이 규범을 실현하는 데 있어서의 진전을 평가한다. 모든 주요 브라우저의 핵심 공헌자 중에서 이것은 줄곧 받아들여지고 환영받는 지표이다.

토론 #9

은 우리가 여기서 발견한 바와 같이 이 숫자들은 정확하지 않을 수도 있다.이 지표는 의미가 있기 때문에 칭찬할 만하다.하지만 나는 이것이 사실이라고 의심한다.
백분율이 실현자에 대한 유용성은 이러한 가설에 달려 있다. 전체 규범을 실현하는 것은 격려할 만한 것이고 이것도 논쟁할 만한 것이다.제 입장에서 볼 때 저는 실현자와 프로그래머에 대해 좋은 뜻을 가지고 있습니다. 만약에 이런 기능들이 가능한 한 긴 시간 동안 발송자의 통제를 벗어난다면 우리는 더욱 잘 지낼 수 있을 것입니다.
지표도 너무 구체적이다.100%는 플랫폼을 상호 운용할 수 있음을 의미합니다.최소한 100%의 준수는 다른 어떤 것보다도 공평하게 계산할 수 있다.100퍼센트 이하의 숫자는 실현자나 사용자가 부족한 기능을 이해하기 위해 이 칼럼을 읽어야 한다는 것을 의미한다.만약 어떤 차이가 있다면, 브리 값인 'complete' 이나 'complete' 은 상당히 정확할 수도 있지만, 매우 유용하다.

토론 #10

에는'정확성'목표가 없습니다.그것들은 단지 실현자가 사물을 실현하면서 증가하는 임의의 숫자일 뿐이다.0에서 100으로 발전하는 것은 매우 유용하다. 단지 진보를 평가하고 사람들로 하여금 양호하게 느끼게 하기 위해서이다.또한 이러한 기능이 지연되기를 바라는 것은 완전히 소극적이고 쓸모없는 태도이며, 모든 기능이 놀라운 속도로 모든 브라우저에서 실현되기를 바란다.모든 미래의 규격은 두 개의 브라우저가 이미 발표한 것만 포함될 것이다.
ES5를 사용하더라도 100% 호환되는 엔진은 없습니다.목표는'100퍼센트 혹은 아무것도 없다'가 아니다. 그것은 이원이 아니다.

토론 #11

나는 약간의 관점을 제공하려고 한다.우리가 무엇을 '진보' 와 '유용성' 을 구성하는지에 대한 견해는 아마도 조화롭지 못할 것이다.이 탁자를 실행자로 배로 늘리는 게임을 통해 당신은 이미 개인 철학을 그 안에 주입시켰다.나는 너희들에게 이 통계 데이터를 정화하라고 촉구한다.피쳐의 장점 및/또는 크기를 다른 곳에서 강조합니다.

토론 #12

만약에 내가 비교적 적은 용어('소형','소형','중','대형'일 수도 있고,'특징'과 같은 대상에게'유용','중요','지표'를 대체할 수 있다면 나도 이렇게 할 수 있다.

The usefulness of a percentage to implementors hinges on the supposition that implementing the entire spec is worth encouraging, which is also debatable.

음...JS의 역사상 당시의 규범에서 벗어난 것이 가치 있는 상황이다. 주의해야 할 예는 ES5에서 대상 텍스트의 중복 속성 이름 제한이다. 실현 인원은 이 제한을 삭제해야만 ES6를 실현할 수 있다.만약 어떤 ES6 기능이 개발해서는 안 된다는 사실이 증명된다면 이러한 역전은 틀림없이 미래의 규범에서 끝날 것이다. 예를 들어 ES7이나 ES8이다.이를 고수하는 플랫폼은 더 이상 ES6의 100%를 보유하지 않지만 운영 중 ES7의 100%에 육박할 것이므로 더욱 가치 있는 목표로 여겨질 것이다.따라서'실시 ES6'라는 개념이 문화적 명성을 가진 상황에서 이 표의 점수는'100% 실시 ES6'에 불과하다.

토론 #13

@jacksonrayhamilton은 개인 철학을 사물에 주입하는 데 잘못이 없고 개인 철학이 없으면 사물이'더 순결하지 않다'고 할 수 없다.만약 당신이 어떤 일의 개인 철학에 동의하지 않는다면, 포크를 자유롭게 눌러서 자신의 변체를 만들 수 있다.

토론 #14

It's quite useful - implementors (ie, browser developers) constantly use those numbers to gauge their progress in implementing the spec. It's long been an accepted and welcomed metric amongst core contributors of all of the major browsers.

나 개인적으로는 점수가 임의적이어서 분류에 그다지 동의하지 않는다.그리고 엄격한 패턴 같은 것에 대해 이야기하기 시작하면, 실현해야만 20% 의 신용을 얻을 수 있고, 더욱 독단적으로 변하기 시작한다.이 실현자는 채점 알고리즘에 관심이 있다기보다는 생태계에 대해 아름다운 3048미터의 시각을 가지고 있다.
목표는 대부분의 개발자들이 인정할 수 있는 숫자를 대표하는 것이어야 한다.이것은 해결하기 어려운 문제이기 때문에 나는 현재의 시도가 전체적으로 합리적인 것 같다고 생각한다.

토론 #15

모든 관점에 동의합니다!

토론 #16

여러분, 저희는 섣불리 결론을 내리지 말고'포크'를 자유롭게 클릭하고 변체를 할 수 있습니다'.
우리는 모두compat table가 유용하고 공평한 자원이 되기를 희망합니다. 따라서 @jacksonrayhamilton, 이 질문을 해 주셔서 감사합니다.불행하게도 @bterlson과 다른 사람들이 언급한 것처럼 공평은 어렵다.우리는 표를 완전히 객관화할 수 없다. 왜냐하면 기능 '그룹' 아래에서 테스트를 객관적으로 그룹으로 나눌 수 없기 때문이다.
예를 들어 공식 ECMA262 테스트 세트에서 112/956와 같은 결과를 간단하게 나타낼 수 있습니다. 테스트를 통과한 수량과 전체 테스트의 수량의 비례입니다.그러나 우리의 예에서 우리는 더욱 우호적인 개술을 하고 싶다.이것은 분명히 주관적인 결정에 수반된다.
개인 철학은 역사적으로 기준을 발전시키는 데 큰 역할을 했다.2005년 Acid 2 테스트 기억나세요?이것은 각종 기술/표준(html,svg 등)에 대한 주관적인 테스트이다.만약 당신이 예쁜 웃는 얼굴을 가지고 있다면, 당신의 브라우저가 통과될 것입니다.브라우저 공급업체들은 미친 듯이 이 규정을 준수했다.봐라, 우리는 모든 주요 브라우저에 acid 테스트의 내용을 추가하거나 복구했다.이런 일은 어리석어 보일 수도 있지만, 그것들은 매우 중요하고 효과적이다.만약 compat표와 같은 주관적인 자원이 없다면 현재 ES6의 진전은 그렇게 빠르고 광범위하지 않을 것이다.
우리는 어떤 상식을 따르려고 했지만, 항상 개선 건의를 듣기 좋아한다.많은 사람들이 어떤 기능들이 더 높은 점수를 받아야 한다고 생각한다면 들어보자.

토론 #17

은 완성 비율을 제공하는 것이 목표이기 때문에 더 좋은 방법은 @webbedspace가 제안한 방법이라고 생각합니다.'미소','소','중'과'대'를 사용하여 기능의 상대적인 크기를 나타냅니다(예를 들어 그것을 실현하는 데 통상적으로 필요한 시간과 정력을 추측하는 것).
예를 들어SICP에서 얻은 인상은 똑똑하지만 간단한 컴파일러 최적화로 끝부분 호출이 가능하다는 것이다.나는 이것이 JS에서 매우 간단한지 모르겠지만, 만약 그렇다면 그것은 미소한 특성이 될 것이다.

토론 #18

은 주제에서 벗어났지만 JS 가상 기기의 경우 꼬리 호출이 쉽지 않다.만약 우리가 논쟁에 대해 생각하지 않는다면전보를 보낸 사람, 잘못."스택과 유사한""에지 상태""는""단순""에 가까울 수 있지만 그래도 끝부분 호출로 인해 성능이 저하되는 것을 원하지 않는 경우에는 많은 작업이 필요합니다."

토론 #19

은 the wording has been changed처럼 보입니다. 이 문제를 해결해 주셔서 감사합니다.