2012 년 2 월 수정 : 아래 답변은 더 이상 정확하지 않습니다. __proto__는 ECMAScript 6에 "표준 선택 사항"으로 추가되고 있습니다. 이는 구현할 필요는 없지만 구현할 경우 주어진 규칙 집합을 따라야 함을 의미합니다. 이것은 현재 해결되지 않았지만 적어도 공식적으로 JavaScript 사양의 일부가 될 것입니다.
이 질문은 표면적으로 보이는 것보다 훨씬 더 복잡하며 Javascript 내부에 대한 지식과 관련하여 대부분의 사람들의 급여 등급 이상입니다.
prototype
개체 의 속성은 해당 개체의 새 자식 개체를 만들 때 사용됩니다. 변경은 객체 자체에 반영되지 않고 해당 객체가 다른 객체의 생성자로 사용될 때 반영되며 기존 객체의 프로토 타입을 변경하는 데 사용되지 않습니다.
function myFactory(){};
myFactory.prototype = someOtherObject;
var newChild = new myFactory;
newChild.__proto__ === myFactory.prototype === someOtherObject; //true
객체에는 현재 프로토 타입을 가리키는 내부 [[prototype]] 속성이 있습니다. 작동 방식은 객체의 속성이 호출 될 때마다 객체에서 시작하여 루트 객체 프로토 타입 이후에 일치하거나 실패 할 때까지 [[prototype]] 체인을 통해 올라갑니다. 이것이 자바 스크립트가 객체의 런타임 빌드 및 수정을 허용하는 방법입니다. 필요한 것을 검색 할 계획이 있습니다.
__proto__
속성은 (지금은 많이) 일부 구현에 존재 : 모질라 구현, 내가 아는 모든 웹킷 사람, 어떤 다른 사람을. 이 속성은 내부 [[prototype]] 속성을 가리키며 객체 생성 후 수정을 허용합니다. 이 연결 조회로 인해 모든 속성 및 기능이 프로토 타입과 일치하도록 즉시 전환됩니다.
이 기능은 현재 표준화되었지만 여전히 JavaScript의 필수 부분은 아니며이를 지원하는 언어에서는 코드가 "최적화되지 않은"범주로 떨어질 가능성이 높습니다. JS 엔진은 코드, 특히 자주 액세스되는 "핫"코드를 분류하기 위해 최선을 다해야하며 수정과 같은 멋진 작업을 수행하는 경우 __proto__
코드를 전혀 최적화하지 않습니다.
이 게시물은 https://bugzilla.mozilla.org/show_bug.cgi?id=607863의 현재 구현 __proto__
과 그 차이점에 대해 구체적으로 설명 합니다. 모든 구현은 어렵고 해결되지 않은 문제이기 때문에 다르게 수행합니다. a.) 구문 b.) 호스트 객체 (DOM은 기술적으로 Javascript 외부에 있음) 및 c.)를 제외하고 Javascript의 모든 것은 변경 가능합니다 __proto__
. 나머지는 전적으로 귀하와 다른 모든 개발자의 손에 있으므로 __proto__
엄지 손가락처럼 튀어 나온 이유를 알 수 있습니다 .
다른 방법으로는 __proto__
불가능한 일이 있습니다. 런타임시 생성자와 별개로 객체 프로토 타입을 지정하는 것입니다. 이것은 중요한 사용 사례이며 __proto__
아직 죽지 않은 주된 이유 중 하나입니다 . Harmony 공식화에서 진지한 논의가되거나 곧 ECMAScript 6으로 알려질만큼 중요합니다. 생성 중에 객체의 프로토 타입을 지정하는 기능은 Javascript의 다음 버전의 일부가 될 것입니다. __proto__
의 날을 나타내는 종 은 공식적으로 번호가 매겨져 있습니다.
단기적 __proto__
으로는이를 지원하는 브라우저를 대상으로 하는 경우 사용할 수 있습니다 (IE가 아니고 IE도 지원하지 않음). ES6는 2013 년까지 완성되지 않기 때문에 향후 10 년 동안 웹킷과 moz에서 작동 할 것입니다.
Brendan Eich -re : ES5의 새로운 Object 메서드 접근 방식 :
죄송합니다, ...하지만 settable __proto__
은 객체 이니셜 라이저 사용 사례 (예 : 아직 도달 할 수없는 새 객체에 대해 ES5의 Object.create와 유사 함)를 제외하고 끔찍한 아이디어입니다. 저는 __proto__
12 년 전에 settable을 설계하고 구현 한이 글을 씁니다 .
... 계층화의 부족이 문제입니다 (키가있는 JSON 데이터 고려 "__proto__"
). 그리고 더 나쁜 것은 가변성이 있다는 것은 구현이 ilooping을 피하기 위해 순환 프로토 타입 체인을 확인해야 함을 의미합니다. [무한 재귀에 대한 지속적인 검사 필요]
마지막으로 __proto__
기존 객체를 변경 하면 새 프로토 타입 객체에서 제네릭이 아닌 메서드가 손상 될 수 있으며, 이는 __proto__
설정중인 수신자 (직접) 객체에서 작동 할 수 없습니다 . 이것은 일반적으로 의도적 인 유형 혼란의 한 형태 인 단순히 나쁜 습관입니다.