[정호] Object.values / Object.entries #7
Conversation
|
|
||
| `Object.keys`와의 일관성은 이 제안에서 가장 중요합니다. 그러나 iterator에 대한 후속 제안은 `Reflect.ownValues` 및 `Reflect.ownEntries`일 가능성이 높으며, 이는 문자열 값 및 Symbol 값 속성의 배열을 모두 제공하는 `Reflect.ownKeys`로 세 가지 요소(key, values, entries)를 완성합니다. 그러나 이 제안은 `Object.values`/`Object.entries`에 초점을 맞추고 있으며 `Object` 또는 `Reflect` 형식의 존재가 다른 형식의 존재에 간섭해서는 안 됩니다. 또한 `keys`/`values`/`entries`에서 iterator를 반환하는 현재 선례는 현재 프로토타입의 메서드에만 적용되며 "`Objects`는 특별하다"는 말이 많은 사람들에게 받아들여지는 것 같습니다. 또한 배열 자체는 이미 반복 가능합니다. | ||
|
|
||
| ## 폴리필 |
There was a problem hiding this comment.
원본 번역만 넣어야 할지 추가로 넣고자 하는 부분도 넣어야 할지 고민하다가 일단 넣었습니다. (폴리필 부분)
There was a problem hiding this comment.
원본 번역만 넣고 폴리필 부분은 src/summary에 넣는것은 어떠세요?
|
|
||
| 반복(iteration) 또는 직렬화(serialization)를 위해 객체에서 키/값 쌍의 배열(스펙에서의 "enries”)을 얻는 것 또한 유용합니다. 예를 들어 반복가능한 `entries` 와 `entries` iterator를 `Map` 생성자가 받을 수 있는 것은 `entries` 배열을 새 `Map`으로 전달하여, 일반 객체를 `Map`으로 빠르게 변환하는게 가능해졌습니다. | ||
|
|
||
| 우리는 이미 객체의 키값들을 배열로 반환하는 `Object.keys`와 `Map`/`Set`/`Array` 에서 일치하는 `keys`/`values`/`entries` iterator 객체를 반환한 선례를 가지고 있습니다. 따라서, es-discuss와 이전 TC39 회의에서 논의된 내용에 따라, 본 제안서는 ECMAScript에 `Object.values`와 `Object.entries`를 추가하고자 합니다. `Object.keys`와 같이 이 두 함수는 배열을 반환하게 될 것 입니다. 이 배열들의 순서는 `Object.keys`의 순서와 정확히 동일하며, 각각 반환된 세 배열은 객체의 key, value, entry를 반영하게 됩니다. |
There was a problem hiding this comment.
iterator라는 단어를 '반복자'로 번역해야할지 의문입니다.
There was a problem hiding this comment.
mdn에 보면 반복자로 번역되어 있어서 반복자로 수정하는게 나아보이긴 합니다..😅
There was a problem hiding this comment.
여기에 전설의 triplets이 등장하는군요 ㅋㅋㅋ
There was a problem hiding this comment.
저는 개인적으로 iterator라고 그대로 놔두는걸 선호하는데요, 번역하게 된다면 반복자(iterator) 이렇게 해주는게 좋다고 생각합니다.
|
|
||
| 객체를 해시 필터로 사용할 때와 같이, 객체의 자체 값(values)을 필요로 하는 경우가 많습니다. 그리고 lodash/underscore, jQuery, Backbone 등 많은 라이브러리들이 “values” 함수를 가지고 있습니다. | ||
|
|
||
| 반복(iteration) 또는 직렬화(serialization)를 위해 객체에서 키/값 쌍의 배열(스펙에서의 "enries”)을 얻는 것 또한 유용합니다. 예를 들어 반복가능한 `entries` 와 `entries` iterator를 `Map` 생성자가 받을 수 있는 것은 `entries` 배열을 새 `Map`으로 전달하여, 일반 객체를 `Map`으로 빠르게 변환하는게 가능해졌습니다. |
There was a problem hiding this comment.
| 반복(iteration) 또는 직렬화(serialization)를 위해 객체에서 키/값 쌍의 배열(스펙에서의 "enries”)을 얻는 것 또한 유용합니다. 예를 들어 반복가능한 `entries` 와 `entries` iterator를 `Map` 생성자가 받을 수 있는 것은 `entries` 배열을 새 `Map`으로 전달하여, 일반 객체를 `Map`으로 빠르게 변환하는게 가능해졌습니다. | |
| 반복(iteration) 또는 직렬화(serialization)를 위해 객체에서 키/값 쌍의 배열(스펙에서의 "entries”)을 얻는 것 또한 유용합니다. 예를 들어 반복가능한 `entries` 와 `entries` iterator를 `Map` 생성자가 받을 수 있는 것은 `entries` 배열을 `new Map`으로 전달하여, 일반 객체를 `Map`으로 빠르게 변환하는게 가능해졌습니다. |
There was a problem hiding this comment.
| 반복(iteration) 또는 직렬화(serialization)를 위해 객체에서 키/값 쌍의 배열(스펙에서의 "enries”)을 얻는 것 또한 유용합니다. 예를 들어 반복가능한 `entries` 와 `entries` iterator를 `Map` 생성자가 받을 수 있는 것은 `entries` 배열을 새 `Map`으로 전달하여, 일반 객체를 `Map`으로 빠르게 변환하는게 가능해졌습니다. | |
| 순회 또는 직렬화를 위해 객체에서 키/값 쌍의 배열(사양에서의 '항목(entries)')을 얻는 것 또한 유용합니다. `Map` 생성자가 순회 가능한 `entries`와 관련된 `entries` 반복자(`WeakMap`도 생성자에서 순회 가능한 `entries`을 허용함)를 수용함에 따라, `entries` 배열을 `new Map`으로 전달하여 일반 객체를 `Map`으로 빠르게 변환하고자 할 때 매우 강력해집니다. |
- loop와 구분하기위해 순회로 번역했습니다.
- 3 Line의 일관성을 위해 사양으로 수정했습니다.
|
|
||
| 반복(iteration) 또는 직렬화(serialization)를 위해 객체에서 키/값 쌍의 배열(스펙에서의 "enries”)을 얻는 것 또한 유용합니다. 예를 들어 반복가능한 `entries` 와 `entries` iterator를 `Map` 생성자가 받을 수 있는 것은 `entries` 배열을 새 `Map`으로 전달하여, 일반 객체를 `Map`으로 빠르게 변환하는게 가능해졌습니다. | ||
|
|
||
| 우리는 이미 객체의 키값들을 배열로 반환하는 `Object.keys`와 `Map`/`Set`/`Array` 에서 일치하는 `keys`/`values`/`entries` iterator 객체를 반환한 선례를 가지고 있습니다. 따라서, es-discuss와 이전 TC39 회의에서 논의된 내용에 따라, 본 제안서는 ECMAScript에 `Object.values`와 `Object.entries`를 추가하고자 합니다. `Object.keys`와 같이 이 두 함수는 배열을 반환하게 될 것 입니다. 이 배열들의 순서는 `Object.keys`의 순서와 정확히 동일하며, 각각 반환된 세 배열은 객체의 key, value, entry를 반영하게 됩니다. |
There was a problem hiding this comment.
여기에 전설의 triplets이 등장하는군요 ㅋㅋㅋ
|
|
||
| 반복(iteration) 또는 직렬화(serialization)를 위해 객체에서 키/값 쌍의 배열(스펙에서의 "enries”)을 얻는 것 또한 유용합니다. 예를 들어 반복가능한 `entries` 와 `entries` iterator를 `Map` 생성자가 받을 수 있는 것은 `entries` 배열을 새 `Map`으로 전달하여, 일반 객체를 `Map`으로 빠르게 변환하는게 가능해졌습니다. | ||
|
|
||
| 우리는 이미 객체의 키값들을 배열로 반환하는 `Object.keys`와 `Map`/`Set`/`Array` 에서 일치하는 `keys`/`values`/`entries` iterator 객체를 반환한 선례를 가지고 있습니다. 따라서, es-discuss와 이전 TC39 회의에서 논의된 내용에 따라, 본 제안서는 ECMAScript에 `Object.values`와 `Object.entries`를 추가하고자 합니다. `Object.keys`와 같이 이 두 함수는 배열을 반환하게 될 것 입니다. 이 배열들의 순서는 `Object.keys`의 순서와 정확히 동일하며, 각각 반환된 세 배열은 객체의 key, value, entry를 반영하게 됩니다. |
There was a problem hiding this comment.
저는 개인적으로 iterator라고 그대로 놔두는걸 선호하는데요, 번역하게 된다면 반복자(iterator) 이렇게 해주는게 좋다고 생각합니다.
|
|
||
| `Object.keys`와의 일관성은 이 제안에서 가장 중요합니다. 그러나 iterator에 대한 후속 제안은 `Reflect.ownValues` 및 `Reflect.ownEntries`일 가능성이 높으며, 이는 문자열 값 및 Symbol 값 속성의 배열을 모두 제공하는 `Reflect.ownKeys`로 세 가지 요소(key, values, entries)를 완성합니다. 그러나 이 제안은 `Object.values`/`Object.entries`에 초점을 맞추고 있으며 `Object` 또는 `Reflect` 형식의 존재가 다른 형식의 존재에 간섭해서는 안 됩니다. 또한 `keys`/`values`/`entries`에서 iterator를 반환하는 현재 선례는 현재 프로토타입의 메서드에만 적용되며 "`Objects`는 특별하다"는 말이 많은 사람들에게 받아들여지는 것 같습니다. 또한 배열 자체는 이미 반복 가능합니다. | ||
|
|
||
| ## 폴리필 |
There was a problem hiding this comment.
원본 번역만 넣고 폴리필 부분은 src/summary에 넣는것은 어떠세요?
| @@ -0,0 +1,47 @@ | |||
| # Object.values / Object.entries | |||
There was a problem hiding this comment.
| # Object.values / Object.entries | |
| # [Object.values](https://github.com/es-shims/Object.values) / [Object.entries](https://github.com/es-shims/Object.entries) |
누락된 링크 추가했습니다.
| @@ -0,0 +1,47 @@ | |||
| # Object.values / Object.entries | |||
|
|
|||
| `Object.values`/`Object.entries` 에 대한 ECMAScript 제안, 사양 및 참조 구현 | |||
There was a problem hiding this comment.
| `Object.values`/`Object.entries` 에 대한 ECMAScript 제안, 사양 및 참조 구현 | |
| `Object.values`/`Object.entries` 에 대한 ECMAScript 제안, 사양 및 참조 구현. |
일관성을 유지하기 위해 . 마침표를 추가했습니다.
|
|
||
| [@ljharb](https://github.com/ljharb) 가 초안을 작성한 사양. | ||
|
|
||
| 이 제안은 현재 [프로세스](https://tc39.github.io/process-document/) 의 [stage 4](https://github.com/tc39/ecma262) 에 있으며 ES 2017에 포함될 예정입니다. |
There was a problem hiding this comment.
저의 경우 위와같이 번역했습니다. 최대한 번역할 수 있는 부분들은 번역하는것을 지향해야한다고 생각합니다. 전체 과정이 원문 그대로 표현한것이 아니기에 조금 걸리지만.. 더 잘 표현한다고 생각해서 전체를 붙였습니다. 의견 부탁드려요!
|
|
||
| 지정된 TC39 검토자: @wycats @littledan @rwaldron | ||
|
|
||
| [Engine Implementations(구현 엔진)](https://github.com/tc39/proposal-object-values-entries/issues/10) |
There was a problem hiding this comment.
| [Engine Implementations(구현 엔진)](https://github.com/tc39/proposal-object-values-entries/issues/10) | |
| [Engine Implementations(엔진 구현)](https://github.com/tc39/proposal-object-values-entries/issues/10) |
엔진 구현이 조금 더 자연스러워 보여서 리뷰 드렸습니다.
|
|
||
| ## 이론적 근거 | ||
|
|
||
| 객체를 해시 필터로 사용할 때와 같이, 객체의 자체 값(values)을 필요로 하는 경우가 많습니다. 그리고 lodash/underscore, jQuery, Backbone 등 많은 라이브러리들이 “values” 함수를 가지고 있습니다. |
There was a problem hiding this comment.
| 객체를 해시 필터로 사용할 때와 같이, 객체의 자체 값(values)을 필요로 하는 경우가 많습니다. 그리고 lodash/underscore, jQuery, Backbone 등 많은 라이브러리들이 “values” 함수를 가지고 있습니다. | |
| 예를 들어, 객체를 해시 필터로 사용할 때와 같이 객체의 자체 값이 필요한 매우 일반적인 사용 사례입니다. lodash/underscore, jQuery, Backbone 등 많은 라이브러리들이 “values” 함수를 가지고 있습니다. |
It is a very common use case to need the own values of an object - for example, when using an object as a hash filter
최대한 원문 그대로의 번역을 지향합니다.
또한, 값(values) 괄호는 가독성에 좋지 못하므로 특수한 경우가 아니고서는 사용을 지양해야합니다. 혹시 괄호를 사용하신 이유가 있을까요?
|
|
||
| 반복(iteration) 또는 직렬화(serialization)를 위해 객체에서 키/값 쌍의 배열(스펙에서의 "enries”)을 얻는 것 또한 유용합니다. 예를 들어 반복가능한 `entries` 와 `entries` iterator를 `Map` 생성자가 받을 수 있는 것은 `entries` 배열을 새 `Map`으로 전달하여, 일반 객체를 `Map`으로 빠르게 변환하는게 가능해졌습니다. | ||
|
|
||
| 우리는 이미 객체의 키값들을 배열로 반환하는 `Object.keys`와 `Map`/`Set`/`Array` 에서 일치하는 `keys`/`values`/`entries` iterator 객체를 반환한 선례를 가지고 있습니다. 따라서, es-discuss와 이전 TC39 회의에서 논의된 내용에 따라, 본 제안서는 ECMAScript에 `Object.values`와 `Object.entries`를 추가하고자 합니다. `Object.keys`와 같이 이 두 함수는 배열을 반환하게 될 것 입니다. 이 배열들의 순서는 `Object.keys`의 순서와 정확히 동일하며, 각각 반환된 세 배열은 객체의 key, value, entry를 반영하게 됩니다. |
There was a problem hiding this comment.
| 우리는 이미 객체의 키값들을 배열로 반환하는 `Object.keys`와 `Map`/`Set`/`Array` 에서 일치하는 `keys`/`values`/`entries` iterator 객체를 반환한 선례를 가지고 있습니다. 따라서, es-discuss와 이전 TC39 회의에서 논의된 내용에 따라, 본 제안서는 ECMAScript에 `Object.values`와 `Object.entries`를 추가하고자 합니다. `Object.keys`와 같이 이 두 함수는 배열을 반환하게 될 것 입니다. 이 배열들의 순서는 `Object.keys`의 순서와 정확히 동일하며, 각각 반환된 세 배열은 객체의 key, value, entry를 반영하게 됩니다. | |
| 우리는 이미 자신의 키 배열을 반환하는 `Object.keys`와 `Map`/`Set`/`Array`에서 일치하는 `keys`/`values`/`entries` 반복자의 세 쌍을 반환하는 선례를 가지고 있습니다. 이와 같이, es-discuss에 대한 토론과 적어도 하나의 이전 TC39 회의에서 이 제안서는 ECMAScript에 `Object.values` 및 `Object.entries`를 추가하려고 합니다. `Object.keys`와 마찬가지로, 이 두 메서드는 배열을 반환합니다. 이 배열들의 순서는 `Object.keys` 순서와 정확히 일치하여, 세 결과 배열의 모든 인덱스가 객체의 동일한 키, 값 또는 항목을 반영합니다. |
There was a problem hiding this comment.
저는 개인적으로 iterator라고 그대로 놔두는걸 선호하는데요, 번역하게 된다면 반복자(iterator) 이렇게 해주는게 좋다고 생각합니다.
반복자(iterator)은 가독성을 저해해서 되도록이면 iterator나 반복자으로 번역하는 것이 좋습니다.
inline code block 이외의 것들은 모두 한글로 번역해야한다고 생각합니다.
There was a problem hiding this comment.
호찬님 말씀대로 괄호를 사용하면 가독성이 떨어집니다. 한 눈에 읽히지 않기 때문이죠.
그런데 리액트 공식문서에도 괄호를 사용하는 부분이 있어서 그 이유를 생각해보니, 괄호를 사용하면 가독성이 떨어지는 대신 명확성이 올라가기 때문이라고 생각해요. 예시처럼 "비교" 알고리즘이 영어로 "diffing" 알고리즘이라는 것을 설명함으로써 검색 키워드를 제공할 뿐 아니라 비교의 여러 단어들(compare...등등) 중에 "diffing"이라고 명확하게 알려줍니다.
저는 반복자도 여기서 비슷하다고 생각합니다. 반복자라는 한글만 봐서는 잘 와닿지 않아서요!
저희가 번역의 기준을 잡을 때는 가독성과 명확성의 반비례 관계를 생각해서 판단하는게 어떨까요?
최대한 가독성을 위한 번역을 하되, 명확성이 필요한 부분에서는 괄호를 사용해도 되는 쪽으로요
추가로 첨부한 사진에서 재조정(Reconciliation)은 제목에 사용되었기 때문에 가독성을 덜 해친다고도 생각합니다.
There was a problem hiding this comment.
@huckjoo 님 좋은 의견입니다 :)
저는 반복자도 여기서 비슷하다고 생각합니다. 반복자라는 한글만 봐서는 잘 와닿지 않아서요!
잘 와닿는 기준은 사람마다 다르다고 생각합니다.
iterator의 경우 '객체 지향적 프로그래밍에서 배열이나 그와 유사한 자료 구조의 내부의 요소를 순회하는 객체'를 나타내는 용어로 많이 사용이 되어 왔는데요. 일례로 c++ 에 익숙한 사람이라면 반복자라는 단어가 어색하지 않습니다. 보통의 경우에서 언어에 관계없이 반복자는 기본적인 개념으로 사용되고 있습니다.
반면에 React 페이지에서 소개하고 있는 Reconciliation나 diffing 알고리즘은 보통의 경우 React에서 처음 접하는 개념입니다. 이 경우는 괄호 사용 좋다고 생각합니다.
경험상 대부분의 경우 적절한 대체 단어가 있기에 괄호를 사용하지 않아도 의미전달에 문제가 없었습니다. 정말 불가피하게 필요하다고 한다면, 처음 단어가 나올때만 괄호를 사용하여 반복자(iterator)와 같이 표기하고 그 뒤로는 반복자로 표기하는것이 좋다고 생각합니다.
개인적인 의견이라.. 이 부분은 담당하시는 분이 자유롭게 하셔도 좋을것같습니다.
There was a problem hiding this comment.
"잘 와닿는 기준이 사람마다 달라서 그걸 기준으로 할 수 없다"는 말이 이해되네요. 더 명확한 기준을 가져야겠습니다.
처음 단어가 나올때만 괄호를 사용하여 반복자(iterator)와 같이 표기하고 그 뒤로는 반복자로 표기하는것이 좋다고 생각합니다.
이 방법 좋네요~!
There was a problem hiding this comment.
추가적으로 단어가 떠오르지 않아서 상표라는 단어 말고 적절한 단어가 있었는데, 보통의 경우 상표는 번역하지 않는것이 좋습니다.
예를들어 Javascript는 자바스크립트로 번역하지 않고, Javascript로 두는것이 좋습니다. (요건 링크가 잘 안찾아져서 패스하겠습니다.)
|
|
||
| ## 사양 | ||
|
|
||
| 사양을 [마크다운 형식](https://github.com/tc39/proposal-object-values-entries/blob/main/spec.md) 이나 [HTML 문서](http://tc39.github.io/proposal-object-values-entries/)로 볼 수 있습니다. 참고: `Object.{keys,values,entries}`각 함수가 동일한 키 순서를 공유하도록 약간의 사양 리팩토링이 있었습니다. |
There was a problem hiding this comment.
| 사양을 [마크다운 형식](https://github.com/tc39/proposal-object-values-entries/blob/main/spec.md) 이나 [HTML 문서](http://tc39.github.io/proposal-object-values-entries/)로 볼 수 있습니다. 참고: `Object.{keys,values,entries}`각 함수가 동일한 키 순서를 공유하도록 약간의 사양 리팩토링이 있었습니다. | |
| 사양을 [마크다운 형식](https://github.com/tc39/proposal-object-values-entries/blob/main/spec.md)으로 보거나, [HTML 문서](http://tc39.github.io/proposal-object-values-entries/)로 렌더링할 수 있습니다. 참고: `Object.{keys,values,entries}`가 동일한 키 순서를 공유하도록 약간의 사양 리팩토링이 있었습니다. |
대명사의 주체를 찾아서 명시해주는 부분이, 정호님의 번역의 좋은 부분 중 하나라고 생각합니다. 하지만, 해당 문장에서는 'Object.{keys,values,entries}각 함수가' 보다는 'Object.{keys,values,entries}가'가 의미를 조금 더 잘 전달한다고 생각하여 리뷰 드립니다.
|
|
||
| 사양을 [마크다운 형식](https://github.com/tc39/proposal-object-values-entries/blob/main/spec.md) 이나 [HTML 문서](http://tc39.github.io/proposal-object-values-entries/)로 볼 수 있습니다. 참고: `Object.{keys,values,entries}`각 함수가 동일한 키 순서를 공유하도록 약간의 사양 리팩토링이 있었습니다. | ||
|
|
||
| ## Iterators 또는 배열? |
There was a problem hiding this comment.
| ## Iterators 또는 배열? | |
| ## 반복자 또는 배열? |
위에와 일관성 있게 번역해주는것이 좋아 보입니다.
|
|
||
| ## Iterators 또는 배열? | ||
|
|
||
| `Object.keys`와의 일관성은 이 제안에서 가장 중요합니다. 그러나 iterator에 대한 후속 제안은 `Reflect.ownValues` 및 `Reflect.ownEntries`일 가능성이 높으며, 이는 문자열 값 및 Symbol 값 속성의 배열을 모두 제공하는 `Reflect.ownKeys`로 세 가지 요소(key, values, entries)를 완성합니다. 그러나 이 제안은 `Object.values`/`Object.entries`에 초점을 맞추고 있으며 `Object` 또는 `Reflect` 형식의 존재가 다른 형식의 존재에 간섭해서는 안 됩니다. 또한 `keys`/`values`/`entries`에서 iterator를 반환하는 현재 선례는 현재 프로토타입의 메서드에만 적용되며 "`Objects`는 특별하다"는 말이 많은 사람들에게 받아들여지는 것 같습니다. 또한 배열 자체는 이미 반복 가능합니다. |
There was a problem hiding this comment.
| `Object.keys`와의 일관성은 이 제안에서 가장 중요합니다. 그러나 iterator에 대한 후속 제안은 `Reflect.ownValues` 및 `Reflect.ownEntries`일 가능성이 높으며, 이는 문자열 값 및 Symbol 값 속성의 배열을 모두 제공하는 `Reflect.ownKeys`로 세 가지 요소(key, values, entries)를 완성합니다. 그러나 이 제안은 `Object.values`/`Object.entries`에 초점을 맞추고 있으며 `Object` 또는 `Reflect` 형식의 존재가 다른 형식의 존재에 간섭해서는 안 됩니다. 또한 `keys`/`values`/`entries`에서 iterator를 반환하는 현재 선례는 현재 프로토타입의 메서드에만 적용되며 "`Objects`는 특별하다"는 말이 많은 사람들에게 받아들여지는 것 같습니다. 또한 배열 자체는 이미 반복 가능합니다. | |
| `Object.keys`와의 일관성은 이 제안에서 가장 중요합니다. 그러나 반복자에 대한 후속 제안은 `Reflect.ownValues` 및 `Reflect.ownEntries`일 가능성이 높으며, 이는 문자열-값 및 심볼-값 속성의 배열을 모두 제공하는 `Reflect.ownKeys`로 세 가지 요소(키, 값, 항목)를 완성합니다. 그러나 이 제안은 `Object.values`/`Object.entries`에 초점을 맞추고 있으며 `Object` 또는 `Reflect` 형식의 존재가 다른 형식의 존재에 간섭해서는 안 됩니다. 또한 `keys`/`values`/`entries`에서 반복자를 반환하는 현재 선례는 현재 프로토타입의 메서드에만 적용되며 "`Objects`는 특별하다"는 말이 많은 사람들에게 받아들여지는 것 같습니다. 또한 배열 자체는 이미 순회 가능합니다. |
| ## 폴리필 | ||
|
|
||
| [폴리필 링크](https://github.com/tc39/proposal-object-values-entries/blob/main/polyfill.js) | ||
|
|
||
| 아래 네 개의 문법이 선행되어야 합니다. | ||
| - `Array.prototype.reduce` | ||
| - `Object.prototype.propertyIsEnumerable` | ||
| - `Array.prototype.concat` | ||
| - `Reflect.ownKeys` |
There was a problem hiding this comment.
| ## 폴리필 | |
| [폴리필 링크](https://github.com/tc39/proposal-object-values-entries/blob/main/polyfill.js) | |
| 아래 네 개의 문법이 선행되어야 합니다. | |
| - `Array.prototype.reduce` | |
| - `Object.prototype.propertyIsEnumerable` | |
| - `Array.prototype.concat` | |
| - `Reflect.ownKeys` |
원본과 동일하게 번역하고, 이외의 사항은 summary에 작성하는 것이 좋아 보입니다!
번역이 생각보다 어렵네요.. 🥲
마지막 문단이 맥락만 이해가 가고
정확히 무슨 말을 하고 싶은 건지 이해가 잘 안가는데
같이 이해해보는 시간이 필요할 것 같습니다 🤪