zerq

Feel free to test JavaScript's RegExp support right here in your browser. Obviously, JavaScript (or Microsoft's variant JScript) will need to be enabled in your browser for this to work. Since this tester is implemented in JavaScript, it will reflect the features and limitations of your web browser's JavaScript implementation. If you're looking for a general-purpose regular expression tester supporting a variety of regex flavors, grab yourself a copy of RegexBuddy.

Learn how to use the JavaScript RegExp object.

Regexp:

Subject string:

Replacement text:

Result:

JavaScript RegExp Tester Source Code

<SCRIPT LANGUAGE="JavaScript">
<!--
function demoMatchClick() {
    var re = new RegExp(document.demoMatch.regex.value);
    if (document.demoMatch.subject.value.match(re)) {
        alert("Successful match");
    }
    else { alert("No match"); }
}
function demoShowMatchClick() {
    var re = new RegExp(document.demoMatch.regex.value);
    var m = re.exec(document.demoMatch.subject.value);
    if (m == null) { alert("No match"); }
    else {
        var s = "Match at position " + m.index + ":\n";
        for (i = 0; i < m.length; i++) { s = s + m[i] + "\n"; }
        alert(s);
    }
}
function demoReplaceClick() {
    var re = new RegExp(document.demoMatch.regex.value, "g");
    document.demoMatch.result.value = document.demoMatch.subject.value.replace(re, document.demoMatch.replacement.value);
}
// -->
</SCRIPT>
<FORM ID="demoMatch" NAME="demoMatch" METHOD=POST ACTION="javascript:void(0)">
<P>Regexp: <INPUT TYPE=TEXT NAME="regex" VALUE="\bt[a-z]+\b" SIZE=50></P>
<P>Subject string: <INPUT TYPE=TEXT NAME="subject" VALUE="This is a test of the JavaScript RegExp object" SIZE=50></P>
<P><INPUT TYPE=SUBMIT VALUE="Test Match" ONCLICK="demoMatchClick()">
<INPUT TYPE=SUBMIT VALUE="Show Match" ONCLICK="demoShowMatchClick()"></P>
<P>Replacement text: <INPUT TYPE=TEXT NAME="replacement" VALUE="replaced" SIZE=50></P>
<P>Result: <INPUT TYPE=TEXT NAME="result" VALUE="click the button to see the result" SIZE=50></P>
<P><INPUT TYPE=SUBMIT VALUE="Replace" ONCLICK="demoReplaceClick()"></P>
</FORM>

정확히 말하면 ECMA 스크립트의 특징이지만 뭐… ^^ 첫번째, 객체의 생성 var arr = []; var obj = {}; var str = ""; var arr1 = [1,2,3]; var obj1 = {prop1 : 'value1', "prop2" : 'value2'}; Object는 {} 로, Array는 []로 생성할 수 있다. object 를 생성할 때 property 의 이름은 따옴표를 따로 해주지 않아도 prop1의 경우처럼 그냥 사용할 수 있다. 하지만, 혹시라도 있을지 모르는 문제점(prop1이 변수로 선언되어있다던가 하는…)을 미리 방지하기 위해서 따옴표를 붙여주도록 하는게 좋다. 단, 충돌이 없음이 확실하다면 생략해도 무방하다. 두번째, object property의 접근 var obj = { "prop1" : "value1", "prop2" : "value2" }; alert(obj.prop1); alert(obj["prop1"]); . 으로 호출하는 방법, 문자열로 인덱스를 지정하는 방법. 둘 다 사용가능하다. 따라서 다음과 같은 것도 가능하다. var i=2; alert(obj["prop"+i]); 세번째, or 의 사용 var val = predefined_value || "value"; or 연산자로 연결된 값을 처음부터 비교해서 false와 동등하게 처리되는 값이 아니라면 반환한다. false와 동등하게 처리되는 값에는 undefined, null, 숫자0, false가 있다. 위 코드에서는 predefined_value 라는 변수가 정의되어있지 않으면 “value”이라는 값을 val 이라는 변수에 할당한다. 보통 IE와 FF의 이벤트 처리가 다른데 그럴 경우에 다음과 같이 사용하기도 한다. function eventHandler(e) {   var evt = e || window.event; // ... some code } 네번째, 괄호()의 사용 (function(str){   alert(str); })("str"); 괄 호는 괄호안의 내용을 해석/실행해서 결과값을 리턴하는 역할이다. (1+2) 라고 하면 괄호는 1+2를 계산해 3 이라는 값을 리턴하는 것과 마찬가지라는 뜻. 따라서 위처럼 anonymous 함수를 만들어놓고 바로 실행할 수도 있게된다(괄호를 통해 함수객체가 반환되었기 때문). ____________________________________________________ 추가 - 2007.3.25 아래 코멘트들을 보고 혹시 헛갈려 하시는 분들이 있을까봐 정리해드립니다. ---------------------------------------- var obj = new Object; 와 var obj = {}; 은 같은 표현입니다. {}을 이용하면 연관배열처럼 사용할 수는 있지만 여전히 Object 타입이며, 연관배열 타입이라는 것은 존재하지 않습니다. 보는 관점에 따라서 javascript에 객체란 없으며 모두 연관배열처럼 구성되어있다는 입장도 있습니다. 마치, PHP의 클래스들이 배열로 구성된 것과 같은 이치입니다. 하지만, {}가 Object 타입의 인스턴스라는 것에는 이의가 없습니다. 있다면, 다른 분들이 말씀해주실 것으로 압니다. 제 견해로는 아무리 느슨해도 객체는 객체입니다. 유연함이 가능한 스크립트언어의 특성일 뿐, 연관배열이 아닌 동적 프로퍼티 구성이 가능한 것으로 봐야 한다는게 제 의견입니다. 자바스크립트는 내장 함수도 재정의할 수 있을 정도로 유연한 언어입니다. 참고로, PHP에서도 연관배열이 따로 존재하지만, $inst = new Klass; $inst->a = "bc"; $inst->b = "de"; 와 같이 동적으로 프로퍼티를 생성하는게 가능합니다. ---------------------------------------- var obj = {   "a" : "bc",   "b" : "de",   "f" : function() {       alert(this.a);   } }; obj.f(); {}이 Object 타입이 아니라 단순한 연관배열일 뿐이라면 this 는 window 객체가 되어야 하지만 결과는 그렇지 않습니다. 위 표현은 다음과 같이 변경할 수도 있습니다. var obj = new Object; obj.a = "bc"; obj.b = "de"; obj.f = "function() {     alert(this.a); } obj.f(); 완전히 같은 경우입니다. {}은 new Object 와 같은 결과이며, {프로퍼티이름:값}은 new Object를 만들고 프로퍼티와 값을 작성해준 경우입니다. 이는 ECMA-262 문서에 나와있는 내용입니다. 따라서, {}을 연관배열 표현이라고 부르는 것은 잘못된 견해라고 봅니다. 메소드가 없다면 연관배열 혹은 해시라고 부르는 것처럼 사용할 수도 있습니다만, 그렇다고 해서 {}이 연관배열의 표현인 것은 아닙니다. {}은 Object의 인스턴스를 생성하는 Object literal 입니다. 혹시라도 오해없으시길 바랍니다. ______________________________________ 참고로, 지금 Mozilla에서 준비하고 있는 Tamarin 프로젝트에서 ECMA4 엔진을 개발중이며 이 엔진의 결과로 Javascript2 가 나옵니다. Javascript2에는 class 가 생길거라고 하는군요. Taramin 프로젝트에 대해서 쓰다가 좀 길어져서 별도의 글로 다시 작성합니다. ^^;;

License 이 게시물은 저작자에게 모든 권리가 있습니다.

TP™날나리코더   07-03-21 22:17   퍼가요... 퍼가요...

칼솜™   07-03-21 22:50   유용한 정보 감사합니다. 그런데 버전 낮은 브라우저도 지원하나요? 유용한 정보 감사합니다. 그런데 버전 낮은 브라우저도 지원하나요?

BL   07-03-21 23:24   본적은 있는데 설명을 들으니까 더 .. 신기하네요..  거참.. ㅎㅎ 본적은 있는데 설명을 들으니까 더 .. 신기하네요.. 거참.. ㅎㅎ

초싸가지인   07-03-21 23:59   구글소스에 보니 저 마지막 부분있든데.. 흐..이제 이해가 되네요 고니님 자바스크립 강좌란이 있었음 하는 바램.. 구글소스에 보니 저 마지막 부분있든데.. 흐..이제 이해가 되네요 고니님 자바스크립 강좌란이 있었음 하는 바램..

지아쁠젝또   07-03-22 00:50   마지막까지 설명을 해주신 것들이 잘 몰랐던 건데 이렇게 간단히 설명을 해주시니 정말 도움이 많이 됐습니다. 마지막까지 설명을 해주신 것들이 잘 몰랐던 건데 이렇게 간단히 설명을 해주시니 정말 도움이 많이 됐습니다.

TP™ 아쿠아   07-03-22 08:26   솥아님 소스보고 깨달은것 솥아님 ㄳㄳ~ 솥아님 소스보고 깨달은것 솥아님 ㄳㄳ~

Innocence   07-03-22 09:19   좋은 정보 감사드립니다. 어떤책에서 JSON 표기법이라고 해서 봤는데. 보니 더 이해서 ^^; 좋은 정보 감사드립니다. 어떤책에서 JSON 표기법이라고 해서 봤는데. 보니 더 이해서 ^^;

딸기키우자   07-03-22 09:52   잘 봤습니다. 고운하루보내세요 잘 봤습니다. 고운하루보내세요

iamSeeker   07-03-22 09:57   좋은 정보 감사합니다~ 좋은 정보 감사합니다~

피곤해   07-03-22 10:03   좋은 정보 감사합니다. 좋은 정보 감사합니다.

시련   07-03-22 10:12   좋은 정보 감사합니다. 좋은 정보 감사합니다.

호랑이풀   07-03-22 10:43   감사요 감사요

Roddy   07-03-22 10:54   아주 유용한 정보를 알기쉽게 잘 정리하셨네요, var obj = {} 만 잘 사용하면 여러모로 많이 편리하더군요. var APP1 = {}; APP1.aaa = function(a) { alert(a) }; APP1.bbb = function(config) {     alert(config.a);     alert(config.b); } APP1.bbb({a : 1, b : 2}); 아주 유용한 정보를 알기쉽게 잘 정리하셨네요, var obj = {} 만 잘 사용하면 여러모로 많이 편리하더군요. var APP1 = {}; APP1.aaa = function(a) { alert(a) }; APP1.bbb = function(config) { alert(config.a); alert(config.b); } APP1.bbb({a : 1, b : 2});

명랑폐인   07-03-22 11:39   평소 궁금했었는데... 감사합니다. 평소 궁금했었는데... 감사합니다.

부비컴   07-03-22 11:52   좋은데요 감사합니다. 좋은데요 감사합니다.

낭망백수   07-03-22 12:32   {} 이건 연관배열 표현인데, ajax in action 에 따르면 Javascript 에서 객체는 배열로 표현된답니다. 꾸벅~! {} 이건 연관배열 표현인데, ajax in action 에 따르면 Javascript 에서 객체는 배열로 표현된답니다. 꾸벅~!

comefeel   07-03-22 13:19   ㅎㅎ 옛날부터 알고잇었는데 절케 쉽게 갈켜주다니 ~ ㅋㅋ 난저거 뭔지 몰라서 알려고 삽질좀 했는데 ㅋㅋㅋ 참 정보는 좋아여  ~ ㅎㅎ 옛날부터 알고잇었는데 절케 쉽게 갈켜주다니 ~ ㅋㅋ 난저거 뭔지 몰라서 알려고 삽질좀 했는데 ㅋㅋㅋ 참 정보는 좋아여 ~

행복한고니   07-03-22 13:36   배열 비슷하게 표현된다고 해서 그게 배열인 것은 아닙니다. 연관배열처럼 보이는 Object type 입니다. var obj = new Object; 이 표현이나 var obj = {}; 이것은 똑같은 표현입니다. 배열 비슷하게 표현된다고 해서 그게 배열인 것은 아닙니다. 연관배열처럼 보이는 Object type 입니다. var obj = new Object; 이 표현이나 var obj = {}; 이것은 똑같은 표현입니다.

낭망백수   07-03-22 23:05   ^^; 연관배열로 객체가 구현되어있다는 뜻입니다. 실제로 객체지향언어가 아닌 것도 아시리라 생각합니다. 꾸벅~! ^^; 연관배열로 객체가 구현되어있다는 뜻입니다. 실제로 객체지향언어가 아닌 것도 아시리라 생각합니다. 꾸벅~!

comefeel   07-03-23 00:05   JS는 제한적이지만  객체지향 개향 스크립트 언어라 알고 있습니다. 뭐 컴파일 언어랑 크게 다른 면은 없다고 생각이 드네요 ^-^ 아차 딴지는 아닙니다. JS는 제한적이지만 객체지향 개향 스크립트 언어라 알고 있습니다. 뭐 컴파일 언어랑 크게 다른 면은 없다고 생각이 드네요 ^-^ 아차 딴지는 아닙니다.

행복한고니   07-03-23 01:20   객체...라는게 객체지향언어에만 있는건 아닙니다만... 아직까지는 자바스크립트가 객체지향언어가 아니라는 것에는 동의하지만, 객체가 연관배열로 구성되어있다는 말이나 객체지향언어가 아니라는 말은 이해가 안되는군요. 객체가 연관배열로 구성되어있고 그렇기 때문에 객체지향언어가 아니라는 건가요? 내부적으로 어떻게 구성이 되어있든 엄연히 자바스크립트에서 배열과 Object 는 다른 겁니다. 정확히 무슨 말씀을 하시는건지 이해가 안되는군요. 첫번째줄과 두번째줄의 의도를 모르겠습니다. 객체...라는게 객체지향언어에만 있는건 아닙니다만... 아직까지는 자바스크립트가 객체지향언어가 아니라는 것에는 동의하지만, 객체가 연관배열로 구성되어있다는 말이나 객체지향언어가 아니라는 말은 이해가 안되는군요. 객체가 연관배열로 구성되어있고 그렇기 때문에 객체지향언어가 아니라는 건가요? 내부적으로 어떻게 구성이 되어있든 엄연히 자바스크립트에서 배열과 Object 는 다른 겁니다. 정확히 무슨 말씀을 하시는건지 이해가 안되는군요. 첫번째줄과 두번째줄의 의도를 모르겠습니다.

숨어지내리   07-03-23 17:11   낭만백수님의 말이 맞습니다. ㅡㅡ; var obj = new Object(); var obj= {}; 는 엄연히 다릅니다. 똑같다고 보시는것은 무리가 있습니다. var obj = {}; alert(obj === new Object()); -> false ㅡㅡ;; typeof 에만 object 만 나오는것이니깐요.  {} 은 연관배열형태로 구성됩니다. 낭만백수님의 말이 맞습니다. ㅡㅡ; var obj = new Object(); var obj= {}; 는 엄연히 다릅니다. 똑같다고 보시는것은 무리가 있습니다. var obj = {}; alert(obj === new Object()); -> false ㅡㅡ;; typeof 에만 object 만 나오는것이니깐요. {} 은 연관배열형태로 구성됩니다.

행복한고니   07-03-23 17:43   테스트를 하려면 제대로 하셔야죠. alert(({} === {})); alert((new Object === new Object)); alert(({} === new Object)); 세개다 false 입니다. equality 하고 identity 하고 착각하신 것 같습니다. 그리고 Object 가 {} 으로 만들어진다는 말은 자바스크립트의 상위 스펙인 ECMA 표준문서에 있는 내용입니다. 테스트를 하려면 제대로 하셔야죠. alert(({} === {})); alert((new Object === new Object)); alert(({} === new Object)); 세개다 false 입니다. equality 하고 identity 하고 착각하신 것 같습니다. 그리고 Object 가 {} 으로 만들어진다는 말은 자바스크립트의 상위 스펙인 ECMA 표준문서에 있는 내용입니다.

행복한고니   07-03-23 17:49   아... 하나더요. Object.prototype.someFunc = function() { alert('hello~') }; ({}).someFunc(); (new Object).someFunc(); 실행해보면 알겠지만 Object에 prototype을 정의해둬도 {} 에서도 똑같이 사용할 수 있습니다. {}와 new Object는 같은 의미입니다. 아... 하나더요. Object.prototype.someFunc = function() { alert('hello~') }; ({}).someFunc(); (new Object).someFunc(); 실행해보면 알겠지만 Object에 prototype을 정의해둬도 {} 에서도 똑같이 사용할 수 있습니다. {}와 new Object는 같은 의미입니다.

숨어지내리   07-03-23 18:23   // 행복한 고니 Object 와 배열은 다르다는걸 알고 계시네요. 헌데, object 가 {} 으로 만들어진다는 것은 전혀 납득할수가 없습니다. 제가 예로 든 내용도 문제가 있을테이지만, 행복한 고니님의 예제도 썩 좋아보이지 않습니다. Object.prototype.someFunc = function() { alert('hello~') }; ({}).someFunc(); (new Object).someFunc(); (new Array).someFunc(); 똑같이 나오는데, 허면, {} = new Object = new Array  가 되는것인지요? 제가 보는 관점은 Object - {}                                   - Array 와 같이 상속처럼 구현되어져 있고 , {} 은 연관배열(배열의 형태는 필드명에 의한 문자열 인덱스 배열(associative array; 혹은 연상배열) 로 구성된다는 겁니다. ECMA 표준문서에 나와 있다는데 제가 찾아봐도 그런내용은 없고, {} 이게 상위라는 말은 전혀 납득이 되질않습니다. ECMA 에 표기되어 있다하는데, 그부분을 명확히 보여주시어 중생을 가르쳐 주시기 바랍니다. // 행복한 고니 Object 와 배열은 다르다는걸 알고 계시네요. 헌데, object 가 {} 으로 만들어진다는 것은 전혀 납득할수가 없습니다. 제가 예로 든 내용도 문제가 있을테이지만, 행복한 고니님의 예제도 썩 좋아보이지 않습니다. Object.prototype.someFunc = function() { alert('hello~') }; ({}).someFunc(); (new Object).someFunc(); (new Array).someFunc(); 똑같이 나오는데, 허면, {} = new Object = new Array 가 되는것인지요? 제가 보는 관점은 Object - {} - Array 와 같이 상속처럼 구현되어져 있고 , {} 은 연관배열(배열의 형태는 필드명에 의한 문자열 인덱스 배열(associative array; 혹은 연상배열) 로 구성된다는 겁니다. ECMA 표준문서에 나와 있다는데 제가 찾아봐도 그런내용은 없고, {} 이게 상위라는 말은 전혀 납득이 되질않습니다. ECMA 에 표기되어 있다하는데, 그부분을 명확히 보여주시어 중생을 가르쳐 주시기 바랍니다.

행복한고니   07-03-23 18:40   Array 가 Object 를 상속받는 거라서 그렇게 나오긴 하는군요. 예를 든 것은 적절하지 않았던 것 같습니다. 이건 어때요? alert(({}).constructor); alert((new Object).constructor); alert(([]).construcotr); alert((new Array).construcotr);   그 어느 책에서도 "연관배열 타입"이라는 것을 가르치지 않습니다. 그렇게 보일뿐이라니까요. 대체 존재하지도 않는 타입을 있다고 생각하시는 이유가 뭔지 모르겠습니다. -_-;; 자바스크립트와 관련된 표준문서는 ECMA-262입니다. 11.1.5 절 보세요. Object Initialiser 입니다. 그 위에는 Array Initialiser 구요. PDF 로는 53페이지, 쪽번호를 기준으로 하면 41페이지군요. PDF는 아래 주소에서 구할 수 있습니다. http://www.ecma-international.org/publications/standards/Ecma-262.htm MDC에 있는 Javascript 타입이니까 참고하세요. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference Array 가 Object 를 상속받는 거라서 그렇게 나오긴 하는군요. 예를 든 것은 적절하지 않았던 것 같습니다. 이건 어때요? alert(({}).constructor); alert((new Object).constructor); alert(([]).construcotr); alert((new Array).construcotr); 그 어느 책에서도 "연관배열 타입"이라는 것을 가르치지 않습니다. 그렇게 보일뿐이라니까요. 대체 존재하지도 않는 타입을 있다고 생각하시는 이유가 뭔지 모르겠습니다. -_-;; 자바스크립트와 관련된 표준문서는 ECMA-262입니다. 11.1.5 절 보세요. Object Initialiser 입니다. 그 위에는 Array Initialiser 구요. PDF 로는 53페이지, 쪽번호를 기준으로 하면 41페이지군요. PDF는 아래 주소에서 구할 수 있습니다. http://www.ecma-international.org/publications/standards/Ecma-262.htm MDC에 있는 Javascript 타입이니까 참고하세요. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference

숨어지내리   07-03-23 19:11   alert(({}).constructor); alert((new Object).constructor); alert(([]).construcotr); alert((new Array).construcotr); ^^; 위와 같이 예제를 주었는데, array 와 당연히 다를것입니다. 아까도 말씀드렸듯이   Object - {}           - Array 위와 같이 서로 다른 생성자를 생성하고 있고, {} 은 object 를 상속만 받았다고 보입니다. 그리고 당연히 type 에는 연관배열타입은 없습니다. ^^; 하지만, 연관배열이라고 지칭하는 표현이 있기 때문에 그렇게 말씀드린것입니다. 형(type)과 형태는 다른표현입니다. ^^; 더 자세한 예제는 아래 예제를 보는게 더 빠를것 같네요. http://www.quirksmode.org/js/associative.html 보여주신 ECMA 에 대한 문서 내용은 object 처럼 사용할수 있다라는것이지, {} 가 object 를 만들어진다는 말은 없네요. ㅡㅡ,. 어딘지 자세히 알려주세요..ㅠㅠ alert(({}).constructor); alert((new Object).constructor); alert(([]).construcotr); alert((new Array).construcotr); ^^; 위와 같이 예제를 주었는데, array 와 당연히 다를것입니다. 아까도 말씀드렸듯이 Object - {} - Array 위와 같이 서로 다른 생성자를 생성하고 있고, {} 은 object 를 상속만 받았다고 보입니다. 그리고 당연히 type 에는 연관배열타입은 없습니다. ^^; 하지만, 연관배열이라고 지칭하는 표현이 있기 때문에 그렇게 말씀드린것입니다. 형(type)과 형태는 다른표현입니다. ^^; 더 자세한 예제는 아래 예제를 보는게 더 빠를것 같네요. http://www.quirksmode.org/js/associative.html 보여주신 ECMA 에 대한 문서 내용은 object 처럼 사용할수 있다라는것이지, {} 가 object 를 만들어진다는 말은 없네요. ㅡㅡ,. 어딘지 자세히 알려주세요..ㅠㅠ

MC_BirdShim   07-03-23 20:24   숨어지내리님 말씀은 Obejct를 Array,{}가 상속받았다는 뜻인가요?. []는 Array를 상속 받은 것이구요?. 내용 뜻을 잘 이해를 못 하겠어서 여쭙는 거였구요.. ^^;; 잘 하지도 못하는 실력으로 나서는거 같아 송구스러운데.. 개인적인 느낌으로는 {}는 완전히 Object와 같던데요?. prototype.js에서 $()을 document.getElementById 처럼 사용할수 있다라고 하는 뉘앙스랑 비슷하게 느껴져서요.. 숨어지내리님 말씀은 Obejct를 Array,{}가 상속받았다는 뜻인가요?. []는 Array를 상속 받은 것이구요?. 내용 뜻을 잘 이해를 못 하겠어서 여쭙는 거였구요.. ^^;; 잘 하지도 못하는 실력으로 나서는거 같아 송구스러운데.. 개인적인 느낌으로는 {}는 완전히 Object와 같던데요?. prototype.js에서 $()을 document.getElementById 처럼 사용할수 있다라고 하는 뉘앙스랑 비슷하게 느껴져서요..

낭망백수   07-03-23 20:48   객체지향언어의 기본적인 특성을 자바스크립트는 갖추고 있지 않습니다. 이점은 정확히 아시리라 생각합니다. 그렇게 본다면, 객체가 연관배열보다 기반이 되어서 연관배열이 객체로 구현되었다고 보기보다는 반대로 객체(실제로 '객체지향'의 객체가 아니라 type 이 'object'일 뿐인)가 보편적인 개념의 type인 연관배열로 구현되어있다고 보는게 맞다는 것이 제 의견입니다. 최소한 Ajax in action 저자의 견해라면 충분히 권위있다고 생각하구요. 제가 공부하고 있는 시점에서 봐도 그렇다고 동의합니다. 굳이 자바스크립트를 객체지향언어(;oopl)로 분류한다고 하면 prototype-based oopl 로 분류를 할 수가 있는데 그마저도 정확히 prototype-based oopl 인 것은 아니라고 합니다. prototype-based oopl 은 class-based oopl 보다 제가 훨씬 모르는 분야라서 더 이상 설명드리긴 어렵네요. 일단 견해로 받아들이시면 좋겠습니다. 어쨋든 자바스크립트가 제대로 된 객체를 표현하는 것이 아님은 인정하시리라 생각합니다. 꾸벅~! 객체지향언어의 기본적인 특성을 자바스크립트는 갖추고 있지 않습니다. 이점은 정확히 아시리라 생각합니다. 그렇게 본다면, 객체가 연관배열보다 기반이 되어서 연관배열이 객체로 구현되었다고 보기보다는 반대로 객체(실제로 '객체지향'의 객체가 아니라 type 이 'object'일 뿐인)가 보편적인 개념의 type인 연관배열로 구현되어있다고 보는게 맞다는 것이 제 의견입니다. 최소한 Ajax in action 저자의 견해라면 충분히 권위있다고 생각하구요. 제가 공부하고 있는 시점에서 봐도 그렇다고 동의합니다. 굳이 자바스크립트를 객체지향언어(;oopl)로 분류한다고 하면 prototype-based oopl 로 분류를 할 수가 있는데 그마저도 정확히 prototype-based oopl 인 것은 아니라고 합니다. prototype-based oopl 은 class-based oopl 보다 제가 훨씬 모르는 분야라서 더 이상 설명드리긴 어렵네요. 일단 견해로 받아들이시면 좋겠습니다. 어쨋든 자바스크립트가 제대로 된 객체를 표현하는 것이 아님은 인정하시리라 생각합니다. 꾸벅~!

행복한고니   07-03-23 20:48   이해를 잘 못하셨나본데요... {} 와 Object 가 같고, [] 와 Array 가 같다는 의미입니다. constructor 에서 어떤 내용이 출력되는지 보셨는지요? 저... 그리고 주신 페이지 제목만 딱 해석하면요... "연관배열로서의 Object" 거든요? Object 지만, 연관배열처럼 사용할 수 있다라는 뜻입니다. -_-;; ECMA 문서를 드렸는데도 없다고 하시니 답답합니다. Object inialiser 라고 나와있지 않습니까? Object 를 생성할 때 쓴다는 건데요? var obj = { aaa : "hello" , test : function(){ alert(this.aaa); } }; 단순히 연관배열이라면 obj.test(); 를 했을 때, 어째서 그와 같은 결과가 나오는지 다시 한번 잘 생각해보십시오. 단순히 데이터를 저장하는 용도로 사용되는게 아니란 말입니다. 정말... 클래스도 구조체라고 하실 분들이군요. 이해를 잘 못하셨나본데요... {} 와 Object 가 같고, [] 와 Array 가 같다는 의미입니다. constructor 에서 어떤 내용이 출력되는지 보셨는지요? 저... 그리고 주신 페이지 제목만 딱 해석하면요... "연관배열로서의 Object" 거든요? Object 지만, 연관배열처럼 사용할 수 있다라는 뜻입니다. -_-;; ECMA 문서를 드렸는데도 없다고 하시니 답답합니다. Object inialiser 라고 나와있지 않습니까? Object 를 생성할 때 쓴다는 건데요? var obj = { aaa : "hello" , test : function(){ alert(this.aaa); } }; 단순히 연관배열이라면 obj.test(); 를 했을 때, 어째서 그와 같은 결과가 나오는지 다시 한번 잘 생각해보십시오. 단순히 데이터를 저장하는 용도로 사용되는게 아니란 말입니다. 정말... 클래스도 구조체라고 하실 분들이군요.

낭망백수   07-03-23 21:04   '연관배열로 구현되어있다'를 좀 과대해석하시는 느낌입니다. 연관배열이 객체로 구현되어 있다고 하는 것 보다는 보다 타당한 분석아닌가요? (제대로 된 객체가 아니잖아요. ^^;) 서로 무지해서 그런건 아님은 인정하실테니 견해가 다른 걸로 하죠. ㅎㅎ '연관배열로 구현되어있다'를 좀 과대해석하시는 느낌입니다. 연관배열이 객체로 구현되어 있다고 하는 것 보다는 보다 타당한 분석아닌가요? (제대로 된 객체가 아니잖아요. ^^;) 서로 무지해서 그런건 아님은 인정하실테니 견해가 다른 걸로 하죠. ㅎㅎ

숨어지내리   07-03-23 21:47   객체를 구조체로 말하는 짱구는 없을것으로 생각됩니다. ^^; 고니님 말씀이 틀렸다는게 아니라, 그렇게 보이는것입니다. {} 는 분명 Object 를 implements 했을뿐이고, 그렇게 보이는것입니다. 아까 말했듯이 행복한 고니님이 말한 ' Object 가 {} 으로 만들어진다는 말은 ' 이부분이 ECMA 에 어디에 있는지를 알려달라고 말씀드린것입니다. ^^; 물론 Array 또한 Object 를 implements 한것이고요.. alert 에서 구현이 Object 로 구현되었다고 해서 {} 이 Object 라고 표현하는것은 분명 다르다고 말씀드립니다. 객체를 구조체로 말하는 짱구는 없을것으로 생각됩니다. ^^; 고니님 말씀이 틀렸다는게 아니라, 그렇게 보이는것입니다. {} 는 분명 Object 를 implements 했을뿐이고, 그렇게 보이는것입니다. 아까 말했듯이 행복한 고니님이 말한 ' Object 가 {} 으로 만들어진다는 말은 ' 이부분이 ECMA 에 어디에 있는지를 알려달라고 말씀드린것입니다. ^^; 물론 Array 또한 Object 를 implements 한것이고요.. alert 에서 구현이 Object 로 구현되었다고 해서 {} 이 Object 라고 표현하는것은 분명 다르다고 말씀드립니다.

행복한고니   07-03-23 22:54   낭망백수 // 낭망백수님은 최초에 적었던 코멘트를 다시 보세요. "{}은 연관배열표현인데..." 라고 했습니다. 제 글과는 달리 {}는 다른 용도인 것처럼 볼 수도 있는 표현이었다고 생각합니다. Ajax in Action 의 저자는 "자바스크립트에는 객체처럼 보이는 연관배열만이 존재한다"라는 입장이고요. 자바스크립트에 객체가 없다...라는 입장이라면 이 글에서 적합한 토론은 아닌 것 같고요, 둘 중에 한명은 오해가 있었다는 뜻이 되겠죠. 본문의 글은 {} 과 new Object 는 같은 의미다 라는게 제 글의 뜻이었으니까, 거기에 집중하시거나 다른 포럼을 열어주세요. 그게 아니라 {}은 Object와 다르고, {}은 연관배열이다라는 입장이라면 숨어지내리 님과 같은 입장이니 같이 얘기해보시죠. 그리고, 권위를 말씀하시는데, 권위를 따지자면 전 자바스크립트를 만든 Eich씨가 Object 라고 명명한 것을 더 신뢰하겠습니다. 권위자의 관점이라고 모두 옳다고 볼 수는 없다는게 이미 수십년의 역사가 증명해주는데(권위자들끼리도 잘 싸웁니다), 그 사람이 만든 것도 아닌 것을 가지고 권위를 들먹여서 근거를 댈 필요는 없을 것 같은데요? 숨어지내리 // Object initialiser 라니까요. -_-;; Object 타입을 만들때 저렇게도 할 수 있다고 나와있다는 뜻입니다. initialiser 라는 뜻도 제가 알려드려야 하는 것은 아니잖습니까? 제가 알려드린 곳은 제대로 읽어보셨는지요?  바로 다음페이지 첫 머리에 {} 은 new Object 를 실행하고 결과를 리턴한다...라고 되어있습니다. The production ObjectLiteral : { } is evaluated as follows: 1. Create a new object as if by the expression new Object(). 2. Return Result(1). 제가 제 주장의 근거를 대었으니 {}가 Object 를 implement 했으며 {}와 Object는 서로 다른 것이다라는 근거를 들어주세요. 낭망백수 // 낭망백수님은 최초에 적었던 코멘트를 다시 보세요. "{}은 연관배열표현인데..." 라고 했습니다. 제 글과는 달리 {}는 다른 용도인 것처럼 볼 수도 있는 표현이었다고 생각합니다. Ajax in Action 의 저자는 "자바스크립트에는 객체처럼 보이는 연관배열만이 존재한다"라는 입장이고요. 자바스크립트에 객체가 없다...라는 입장이라면 이 글에서 적합한 토론은 아닌 것 같고요, 둘 중에 한명은 오해가 있었다는 뜻이 되겠죠. 본문의 글은 {} 과 new Object 는 같은 의미다 라는게 제 글의 뜻이었으니까, 거기에 집중하시거나 다른 포럼을 열어주세요. 그게 아니라 {}은 Object와 다르고, {}은 연관배열이다라는 입장이라면 숨어지내리 님과 같은 입장이니 같이 얘기해보시죠. 그리고, 권위를 말씀하시는데, 권위를 따지자면 전 자바스크립트를 만든 Eich씨가 Object 라고 명명한 것을 더 신뢰하겠습니다. 권위자의 관점이라고 모두 옳다고 볼 수는 없다는게 이미 수십년의 역사가 증명해주는데(권위자들끼리도 잘 싸웁니다), 그 사람이 만든 것도 아닌 것을 가지고 권위를 들먹여서 근거를 댈 필요는 없을 것 같은데요? 숨어지내리 // Object initialiser 라니까요. -_-;; Object 타입을 만들때 저렇게도 할 수 있다고 나와있다는 뜻입니다. initialiser 라는 뜻도 제가 알려드려야 하는 것은 아니잖습니까? 제가 알려드린 곳은 제대로 읽어보셨는지요? 바로 다음페이지 첫 머리에 {} 은 new Object 를 실행하고 결과를 리턴한다...라고 되어있습니다. The production ObjectLiteral : { } is evaluated as follows: 1. Create a new object as if by the expression new Object(). 2. Return Result(1). 제가 제 주장의 근거를 대었으니 {}가 Object 를 implement 했으며 {}와 Object는 서로 다른 것이다라는 근거를 들어주세요.

숨어지내리   07-03-24 04:55   -------------------------------------------------------------------------------------------------- 먼저 딴지라는 생각보단, 견해라고 생각하시고, 댓글을 보아주셨으면 합니다.^^ 고니님의 견해와 실력은 인정하니깐요. ^^; 단지 제가 생각하는 내용에 대한 부분을 정리하면, 저렇게 만들수도 있다라는것에 대해 반론을 제기하는것이 아니라, {} 와 new Object 는 다르다는 것입니다. (물론 결과적으로는 같습니다. 'new Object 를 실행하고 결과를 리턴한다...라고 되어있습니다. ' 라고 하셨는데, 영어를 해석하면 1. new Object() 객체에 의한것처럼 새로운 객체를 생성한다. 2. Result(1) 을 반환한다. 라고 해석되는것 같은데요. ? ^^; 저게 어떻게 실행해서 결과를 리턴한다라고 해석이 되는지요? ㅡㅡ; 이해할수가 없군요. 또한 제가 문의 드렸던 고니님께서 말씀하신 '그리고 Object 가 {} 으로 만들어진다는 말은 자바스크립트의 상위 스펙인 ECMA 표준문서에 있는 내용입니다. ' 위의 부분이 도대체 어떤부분에 대해 해석을 하셨기에 답변을 하셨는지 여쭤보았는데, 엉뚱하게도, 그부분은 알려주시지를 않고 있군요. 만들어진다라는 표현에 대해 말씀을 드리는것입니다. 이런 비슷한 내용으로 토론을 한 내용을 링크로 보여드리면, http://www.thescripts.com/forum/thread459033.html 위의 주소이며, 내용은 여러가지 이겠으나, 위의 주소를 잘 찾아보시면 The objects created by Object literals inherit directly from the core Object object, not from the core Array object. They inherit indirectly from the Object object, though, through the prototype chain 위와 같이 말하는 내용들을 보실수 있을것입니다. 'Core Object 의 object 로 부터 직접적으로 literals 에 의해 상속되어진것입니다.' 물론 공인된 문서가 아니라고 말할수 있으나, 이렇게 구현되어져 있기 때문에 행복한 고니님이 테스트 하는 결과가 나오는 것입니다. 그래서 " Object.prototype.someFunc = function() { alert('hello~') }; ({}).someFunc(); (new Object).someFunc(); (new Array).someFunc(); 똑같이 나오는데, 허면, {} = new Object = new Array  가 되는것인지요? " 와 같이 이러한 결과가 나오는것이고요..ㅡㅡ; 그러니... ECMA 문서에 표기된 내용만 알려주시면 됩니다. ^^; 그러면, 제가 생각하는 내용이 틀린게 되는것이니깐요. ^^ㅎㅎ -------------------------------------------------------------------------------------------------- 먼저 딴지라는 생각보단, 견해라고 생각하시고, 댓글을 보아주셨으면 합니다.^^ 고니님의 견해와 실력은 인정하니깐요. ^^; 단지 제가 생각하는 내용에 대한 부분을 정리하면, 저렇게 만들수도 있다라는것에 대해 반론을 제기하는것이 아니라, {} 와 new Object 는 다르다는 것입니다. (물론 결과적으로는 같습니다. 'new Object 를 실행하고 결과를 리턴한다...라고 되어있습니다. ' 라고 하셨는데, 영어를 해석하면 1. new Object() 객체에 의한것처럼 새로운 객체를 생성한다. 2. Result(1) 을 반환한다. 라고 해석되는것 같은데요. ? ^^; 저게 어떻게 실행해서 결과를 리턴한다라고 해석이 되는지요? ㅡㅡ; 이해할수가 없군요. 또한 제가 문의 드렸던 고니님께서 말씀하신 '그리고 Object 가 {} 으로 만들어진다는 말은 자바스크립트의 상위 스펙인 ECMA 표준문서에 있는 내용입니다. ' 위의 부분이 도대체 어떤부분에 대해 해석을 하셨기에 답변을 하셨는지 여쭤보았는데, 엉뚱하게도, 그부분은 알려주시지를 않고 있군요. 만들어진다라는 표현에 대해 말씀을 드리는것입니다. 이런 비슷한 내용으로 토론을 한 내용을 링크로 보여드리면, http://www.thescripts.com/forum/thread459033.html 위의 주소이며, 내용은 여러가지 이겠으나, 위의 주소를 잘 찾아보시면 The objects created by Object literals inherit directly from the core Object object, not from the core Array object. They inherit indirectly from the Object object, though, through the prototype chain 위와 같이 말하는 내용들을 보실수 있을것입니다. 'Core Object 의 object 로 부터 직접적으로 literals 에 의해 상속되어진것입니다.' 물론 공인된 문서가 아니라고 말할수 있으나, 이렇게 구현되어져 있기 때문에 행복한 고니님이 테스트 하는 결과가 나오는 것입니다. 그래서 " Object.prototype.someFunc = function() { alert('hello~') }; ({}).someFunc(); (new Object).someFunc(); (new Array).someFunc(); 똑같이 나오는데, 허면, {} = new Object = new Array 가 되는것인지요? " 와 같이 이러한 결과가 나오는것이고요..ㅡㅡ; 그러니... ECMA 문서에 표기된 내용만 알려주시면 됩니다. ^^; 그러면, 제가 생각하는 내용이 틀린게 되는것이니깐요. ^^ㅎㅎ

행복한고니   07-03-24 10:55   숨어지내리 // 저 죄송한데요... literal 이라는 단어를 모르실 분은 아니라고 보는데요? {} 과 new Object 가 다르다는 말은, [] 과 new Array 가 다르며, ""과 new String 이 다르다는 말과 같겠군요. /표현/과 new RegExp 가 다르다는 말도 될 것 같습니다. 1과 new Number(1)은 다른 것이라는 의미도 되겠네요. literal 이라는 단어가 그 문서에서 어떤 용도로 쓰였는지(사실 모든 언어 스펙에서 같은 의미이지만), 한번 잘 살펴보세요. 정말로 1 과 new Number(1)이 다른 걸까요? literal 의 의미도 제가 설명해드려야 하나요? {}은 Object literal 이다 라는 말로 이해하실거라고 생각하고 말씀드렸었는데, 아닌가보군요. 근거로 들었던 것은 누군지도 모르는 어떤 사람의 견해일 뿐이잖습니까? 어째서 그게 주장의 근거가 되는지 모르겠군요. new Object 와 {} 가 다른 점을 한번 설명해주세요. 뭐가 다른가요? 어떠한 주장의 근거도 가지고 있지 못하면서 계속 "주장"만 고집하시는군요. {} 이게 new Object 를 실행한 것과 같은 결과를 리턴한다는데, 그 이상의 다른 말이 필요한지도 모르겠습니다. 그 어떤 문서에서도 {}과 new Object의 차이점을 본 적이 없는데, 무슨 상속을 왜 받은건가요? 표준 문서 어디에 상속이라는 내용이 나와있는지, Object literal 이라는 말이 다르게 해석될 수 있는 이유와 new Object 를 실행한 것과 같은 결과가 어떻게 중간에 상속이 되었다는 뜻으로 해석될 수 있는지와 같은 주장의 근거를 들어주세요. 다시 한번 더 근거도 없이 주장만 하신다면 그냥 그렇게 생각하고 계시라는 말밖에는 드릴 말씀이 없습니다. "{} 은 new Object와 같다" 이런 문장이 없으면 전혀 수긍하지 않으실 분이니까요. P.S// 이왕이면 constructor 가 같은 이유도 좀 들어주세요? 그 코드는 제가 적절하지 않았다고 인정했던 코드인데요? P.S2// 생성자가 같으면서도 서로 다른 자료형일 수 있는 예를 하나 들어주시기 바랍니다. 어느 언어라도 상관없습니다. 숨어지내리 // 저 죄송한데요... literal 이라는 단어를 모르실 분은 아니라고 보는데요? {} 과 new Object 가 다르다는 말은, [] 과 new Array 가 다르며, ""과 new String 이 다르다는 말과 같겠군요. /표현/과 new RegExp 가 다르다는 말도 될 것 같습니다. 1과 new Number(1)은 다른 것이라는 의미도 되겠네요. literal 이라는 단어가 그 문서에서 어떤 용도로 쓰였는지(사실 모든 언어 스펙에서 같은 의미이지만), 한번 잘 살펴보세요. 정말로 1 과 new Number(1)이 다른 걸까요? literal 의 의미도 제가 설명해드려야 하나요? {}은 Object literal 이다 라는 말로 이해하실거라고 생각하고 말씀드렸었는데, 아닌가보군요. 근거로 들었던 것은 누군지도 모르는 어떤 사람의 견해일 뿐이잖습니까? 어째서 그게 주장의 근거가 되는지 모르겠군요. new Object 와 {} 가 다른 점을 한번 설명해주세요. 뭐가 다른가요? 어떠한 주장의 근거도 가지고 있지 못하면서 계속 "주장"만 고집하시는군요. {} 이게 new Object 를 실행한 것과 같은 결과를 리턴한다는데, 그 이상의 다른 말이 필요한지도 모르겠습니다. 그 어떤 문서에서도 {}과 new Object의 차이점을 본 적이 없는데, 무슨 상속을 왜 받은건가요? 표준 문서 어디에 상속이라는 내용이 나와있는지, Object literal 이라는 말이 다르게 해석될 수 있는 이유와 new Object 를 실행한 것과 같은 결과가 어떻게 중간에 상속이 되었다는 뜻으로 해석될 수 있는지와 같은 주장의 근거를 들어주세요. 다시 한번 더 근거도 없이 주장만 하신다면 그냥 그렇게 생각하고 계시라는 말밖에는 드릴 말씀이 없습니다. "{} 은 new Object와 같다" 이런 문장이 없으면 전혀 수긍하지 않으실 분이니까요. P.S// 이왕이면 constructor 가 같은 이유도 좀 들어주세요? 그 코드는 제가 적절하지 않았다고 인정했던 코드인데요? P.S2// 생성자가 같으면서도 서로 다른 자료형일 수 있는 예를 하나 들어주시기 바랍니다. 어느 언어라도 상관없습니다.

낭망백수   07-03-24 13:59   행복한고니 // ^^; 그냥 웃어 넘기겠습니다. 꾸벅~! 행복한고니 // ^^; 그냥 웃어 넘기겠습니다. 꾸벅~!

숨어지내리   07-03-24 14:00   // 행복한 고니 참 희한하군요. 제가 원한건 ECMA 에 대한 부분을 계속 요구하는데도 말씀이없고, 참 이상한 의견만 내놓는 군요. ^^; ㅎ {} 와 new Object 는 inherit 되었으니, 당연히 같은 결과가 나오는데, 엄밀히 따지면 다르니, 결과가 같다고 똑같다고 표현하시는것 자체에 무리가 있다라는 것이고, 영어 해석에 대해 너무 편하신대로 해석하시는것은 아닌지 의문이 드네요..^^; inherit 에 대해서 다시한번 고민해 보셔야 할듯 합니다. 왜 construct 가 같은지.. {} 가  object 를 inherit 했는지는 아래에 코드를 실행해 보시고요. alert(({})); alert(Object); Object 는 core Object 입니다. {} 는 object object 가 되어있을것입니다.ㅡㅡ; 즉 Object 와 {} 는 엄밀히 따지자면 다르다는것입니다. 자꾸 자기주장을 굽히지 않으면서 결과가 같다하여, 자기주장만이 옳고 책에 나와있지 않으니, 수긍할수 없다하니. 참으로다가 고집이 장난이 아닙니다. 자 이제, 이제 제가 보여드린 코드가 상속인지, 정말 object 와 같은지 보여드린것이니, 제가 문의한 고니님이 ECMA 문서에 표기된 Object가 {} 에 의해 만들어진다라는 표현을 알려주시고, 있다 없다 제대로 된 의사전달 해주시고, 있다면, 도대체 ECMA 문서의 몇번째라인부터인지 자세히 알려주십시요. 자신의 편의대로 생각대로 해석한것인지 아니면, 정말 문법에 맞게 해석한것인지가 나올꺼 같네요. 문서에 없더라도 브라우저의 System 상에서 구현이 되어 나오는사항을 가지고 그렇게 우기시는건 도대체 어디서 배운것인지 알다가도 모를일입니다. ps. 남을 깔아뭉개는 것만이 이기는게 아니라, 모르는것은 같이 배우는게 현명한 판단입니다. 잘못된 견해가 다른분들에게는 정설로 받아들여질수 있으니깐요. ps2. "생성자가 같으면서도 서로 다른 자료형일 수 있는 예를 하나 들어주시기 바랍니다" 위와 같이 형(type)이 다르다고 하진 않았습니다. ^^; ㅎㅎ 다만, 생성자가 같은 이유는 {} 이  inherit 되었기 때문이다. 라는 것이고요. // 행복한 고니 참 희한하군요. 제가 원한건 ECMA 에 대한 부분을 계속 요구하는데도 말씀이없고, 참 이상한 의견만 내놓는 군요. ^^; ㅎ {} 와 new Object 는 inherit 되었으니, 당연히 같은 결과가 나오는데, 엄밀히 따지면 다르니, 결과가 같다고 똑같다고 표현하시는것 자체에 무리가 있다라는 것이고, 영어 해석에 대해 너무 편하신대로 해석하시는것은 아닌지 의문이 드네요..^^; inherit 에 대해서 다시한번 고민해 보셔야 할듯 합니다. 왜 construct 가 같은지.. {} 가 object 를 inherit 했는지는 아래에 코드를 실행해 보시고요. alert(({})); alert(Object); Object 는 core Object 입니다. {} 는 object object 가 되어있을것입니다.ㅡㅡ; 즉 Object 와 {} 는 엄밀히 따지자면 다르다는것입니다. 자꾸 자기주장을 굽히지 않으면서 결과가 같다하여, 자기주장만이 옳고 책에 나와있지 않으니, 수긍할수 없다하니. 참으로다가 고집이 장난이 아닙니다. 자 이제, 이제 제가 보여드린 코드가 상속인지, 정말 object 와 같은지 보여드린것이니, 제가 문의한 고니님이 ECMA 문서에 표기된 Object가 {} 에 의해 만들어진다라는 표현을 알려주시고, 있다 없다 제대로 된 의사전달 해주시고, 있다면, 도대체 ECMA 문서의 몇번째라인부터인지 자세히 알려주십시요. 자신의 편의대로 생각대로 해석한것인지 아니면, 정말 문법에 맞게 해석한것인지가 나올꺼 같네요. 문서에 없더라도 브라우저의 System 상에서 구현이 되어 나오는사항을 가지고 그렇게 우기시는건 도대체 어디서 배운것인지 알다가도 모를일입니다. ps. 남을 깔아뭉개는 것만이 이기는게 아니라, 모르는것은 같이 배우는게 현명한 판단입니다. 잘못된 견해가 다른분들에게는 정설로 받아들여질수 있으니깐요. ps2. "생성자가 같으면서도 서로 다른 자료형일 수 있는 예를 하나 들어주시기 바랍니다" 위와 같이 형(type)이 다르다고 하진 않았습니다. ^^; ㅎㅎ 다만, 생성자가 같은 이유는 {} 이 inherit 되었기 때문이다. 라는 것이고요.

낭망백수   07-03-24 14:44   숨어지내리 // 근데 제 말에 동의하시는 듯 하시더니, 또 약간은 다르시군요. ^^; 그리고, 행복한고니 // "Object 가 {} 으로 만들어진다는 말은 자바스크립트의 상위 스펙인 ECMA 표준문서에 있는 내용입니다." 라고 말씀하셨습니다. 'Object 가 {} 으로 만들어진다'가 제가  정작 드리려는 말씀이었습니다. (물론 {} 로 연관배열이 만들어진다는 것도 동의하시리라 생각합니다.) 꾸벅~! 숨어지내리 // 근데 제 말에 동의하시는 듯 하시더니, 또 약간은 다르시군요. ^^; 그리고, 행복한고니 // "Object 가 {} 으로 만들어진다는 말은 자바스크립트의 상위 스펙인 ECMA 표준문서에 있는 내용입니다." 라고 말씀하셨습니다. 'Object 가 {} 으로 만들어진다'가 제가 정작 드리려는 말씀이었습니다. (물론 {} 로 연관배열이 만들어진다는 것도 동의하시리라 생각합니다.) 꾸벅~!

숨어지내리   07-03-24 15:01   낭만백수 // ㅋㅋ ^^; 제가 먼저 고니님께 물어봤습니다.~~ 차례를 지켜주세요~ ㅎ 낭만백수 // ㅋㅋ ^^; 제가 먼저 고니님께 물어봤습니다.~~ 차례를 지켜주세요~ ㅎ

행복한고니   07-03-24 15:01   숨어지내리// 저기 말이죠... 제 글의 본문을 제대로 읽으셨나요? Object는 {}으로 생성할 수 있다는 글이요? 읽으셨나요? {}는 Object와 같은게 아니라 new Object와 같은건데요? 님이 처음에 쓴 글을 보시죠. ______________ var obj = new Object(); var obj= {}; 는 엄연히 다릅니다. 똑같다고 보시는것은 무리가 있습니다. ______________ 라고 했습니다. 그리고 두 가지가 다르다는 것을 보이기 위해서 다음과 같은 예제도 작성하셨죠. ______________ var obj = {}; alert(obj === new Object()); -> false ______________ 그런데, 이제와서 왜 갑자기 {} 와 Object를 비교하세요? 말을 번복하시는게 아니라면 일관성있게 주장해주세요. 저는 new Object와 {}가 같다는 입장이었으니까요. 누가 클래스와 인스턴스가 같다고 주장한답니까? Object 의 type은 function 이거든요? 다시 한번 정리해드리자면, {}로 Object의 인스턴스를 생성할 수 있고, 이것은 new Object 와 같다는 것이 제 입장입니다. 본문에도 그렇게 썼구요. 하지만 님의 의견은 제 입장과는 분명히 달랐었죠. ______________ Object - {}           - Array ______________ 이것처럼 {}가 마치 Object와는 별개의 타입(연관배열이라고 하셨죠?)으로 구성된 것으로 말씀하셨었습니다. 저는 제 주장에 대한 근거로 두가지 방법으로 생성한 객체들의 constructor 가 같다고도 했습니다. ECMA에도 Object 타입의 initializer로 {}가 사용될 수 있다고 써있다고도 알려드렸습니다. 님의 주장이 받아들여지려면 비슷한 의미로 Array initializer 인 [] 은 Array 타입과는 또 다른 타입이어야 맞는 말이 되는 겁니다. 저는 분명 제 주장에 대한 근거를 들었습니다. 거기에 대해서 "Object는 {}로 생성한다"라는 밥을 떠먹여주기를 바라는 문장을 찾으신건지, 인정을 하시려고 안하더군요. 고집인건지 정말 이해를 못하신건지 모르겠지만, 그래서 링크 하나 더 드려보죠. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Object 자바스크립트 1.2 부터 객체의 literal 이 생겨서 new Object는 {}로도 생성할 수 있다고 주석에 나와있습니다. 그런데, {}은 연관배열이고 new Object와는 다르다는 주장의 근거를 못본 것 같네요. System상에서 그렇게 구현이 되어있다는데, 단 한번도 근거를 들어준 적이 없습니다. 제발 주장의 근거를 들어주세요. 엉뚱하게 Object와 {}를 비교하지는 마시고요. 제 주장은 처음부터 지금까지 똑같으니까요. _______________________ 자꾸 자기주장을 굽히지 않으면서 결과가 같다하여, 자기주장만이 옳고 책에 나와있지 않으니, 수긍할수 없다하니. 참으로다가 고집이 장난이 아닙니다. _______________________ "결과가 같다하여" 이 부분만 "근거도 없는데" 라고만 바꾸면 제가 딱 님에게 해드리고 싶은 말이네요. 책은 이미 ECMA 표준문서를 예로 들었습니다. initializer 의 단어 의미를 몰라서라면 이해할 수도 있습니다. 단어의 뜻을 모르신다면 제가 다시 설명드리겠습니다. 단어자체를 몰라도 구글에서 조금만 찾아봐도 어떤 의미로 사용되는지 아실텐데, 검색은 잘 안하시나보네요. P.S// 고집만 피운다고 토론이 되는게 아닙니다. 주장이 되려면 근거가 있어야죠. P.S2// 모르는건 같이 배우는게 현명하지만, 이번 경우엔 제가 일방적으로 당연한 걸 설명하는 입장이라고 생각하고 있습니다. 숨어지내리// 저기 말이죠... 제 글의 본문을 제대로 읽으셨나요? Object는 {}으로 생성할 수 있다는 글이요? 읽으셨나요? {}는 Object와 같은게 아니라 new Object와 같은건데요? 님이 처음에 쓴 글을 보시죠. ______________ var obj = new Object(); var obj= {}; 는 엄연히 다릅니다. 똑같다고 보시는것은 무리가 있습니다. ______________ 라고 했습니다. 그리고 두 가지가 다르다는 것을 보이기 위해서 다음과 같은 예제도 작성하셨죠. ______________ var obj = {}; alert(obj === new Object()); -> false ______________ 그런데, 이제와서 왜 갑자기 {} 와 Object를 비교하세요? 말을 번복하시는게 아니라면 일관성있게 주장해주세요. 저는 new Object와 {}가 같다는 입장이었으니까요. 누가 클래스와 인스턴스가 같다고 주장한답니까? Object 의 type은 function 이거든요? 다시 한번 정리해드리자면, {}로 Object의 인스턴스를 생성할 수 있고, 이것은 new Object 와 같다는 것이 제 입장입니다. 본문에도 그렇게 썼구요. 하지만 님의 의견은 제 입장과는 분명히 달랐었죠. ______________ Object - {} - Array ______________ 이것처럼 {}가 마치 Object와는 별개의 타입(연관배열이라고 하셨죠?)으로 구성된 것으로 말씀하셨었습니다. 저는 제 주장에 대한 근거로 두가지 방법으로 생성한 객체들의 constructor 가 같다고도 했습니다. ECMA에도 Object 타입의 initializer로 {}가 사용될 수 있다고 써있다고도 알려드렸습니다. 님의 주장이 받아들여지려면 비슷한 의미로 Array initializer 인 [] 은 Array 타입과는 또 다른 타입이어야 맞는 말이 되는 겁니다. 저는 분명 제 주장에 대한 근거를 들었습니다. 거기에 대해서 "Object는 {}로 생성한다"라는 밥을 떠먹여주기를 바라는 문장을 찾으신건지, 인정을 하시려고 안하더군요. 고집인건지 정말 이해를 못하신건지 모르겠지만, 그래서 링크 하나 더 드려보죠. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Object 자바스크립트 1.2 부터 객체의 literal 이 생겨서 new Object는 {}로도 생성할 수 있다고 주석에 나와있습니다. 그런데, {}은 연관배열이고 new Object와는 다르다는 주장의 근거를 못본 것 같네요. System상에서 그렇게 구현이 되어있다는데, 단 한번도 근거를 들어준 적이 없습니다. 제발 주장의 근거를 들어주세요. 엉뚱하게 Object와 {}를 비교하지는 마시고요. 제 주장은 처음부터 지금까지 똑같으니까요. _______________________ 자꾸 자기주장을 굽히지 않으면서 결과가 같다하여, 자기주장만이 옳고 책에 나와있지 않으니, 수긍할수 없다하니. 참으로다가 고집이 장난이 아닙니다. _______________________ "결과가 같다하여" 이 부분만 "근거도 없는데" 라고만 바꾸면 제가 딱 님에게 해드리고 싶은 말이네요. 책은 이미 ECMA 표준문서를 예로 들었습니다. initializer 의 단어 의미를 몰라서라면 이해할 수도 있습니다. 단어의 뜻을 모르신다면 제가 다시 설명드리겠습니다. 단어자체를 몰라도 구글에서 조금만 찾아봐도 어떤 의미로 사용되는지 아실텐데, 검색은 잘 안하시나보네요. P.S// 고집만 피운다고 토론이 되는게 아닙니다. 주장이 되려면 근거가 있어야죠. P.S2// 모르는건 같이 배우는게 현명하지만, 이번 경우엔 제가 일방적으로 당연한 걸 설명하는 입장이라고 생각하고 있습니다.

행복한고니   07-03-24 15:04   낭망백수 // 어떤 입장이신가요? 1. Ajax in Action 의 저자처럼 Javascript 엔 객체가 없다. 2. new Object 와 {}은 다른 것이고, {}은 연관배열이다. 제가 예시로 든게 적절하지 않다면 먼저 간단하게 요약부터 해주세요. 제 입장은 "new Object 와 {}은 같은 결과를 도출하고, 둘 다 Object의 인스턴스이다" 입니다. 그 뒤에 다시 토론하죠. 낭망백수 // 어떤 입장이신가요? 1. Ajax in Action 의 저자처럼 Javascript 엔 객체가 없다. 2. new Object 와 {}은 다른 것이고, {}은 연관배열이다. 제가 예시로 든게 적절하지 않다면 먼저 간단하게 요약부터 해주세요. 제 입장은 "new Object 와 {}은 같은 결과를 도출하고, 둘 다 Object의 인스턴스이다" 입니다. 그 뒤에 다시 토론하죠.

낭망백수   07-03-24 15:22   행복한 고니 // 예시에 대해선 전혀 언급할 필요가 없지않나요? 님의 '객체가 {}로 만들어진다'를 저는 '{}로 객체가 표현된다'라고 말하고 있는 중이고, 결론적으로 이견이 아니라고 말씀드린게 제 마지막 커멘트입니다. 유일하게 다른 부분은... 저는 '{}'가 '연관배열표현'이라고 말씀드린 것입니다. 저또한 객체를 생성할때 JSON 및 다른 JS프레임웍과 혼용하기 위해 '{}' 를 즐겨쓰고 있습니다. (이부분에서 배열로 이해하는 것이 상당히 효과적입니다. 개인적으로... ^^) 실용론에 있어서는 다르지 않다는 뜻이지요. 다만 그 내면을 어떻게 보는가 하는 관점의 문제일 뿐입니다. 이만하면 된 것 아닐까요? ^^; 꾸벅~! ps; 객체가 연관배열이라고 볼 수 있는 근거는 '행복한고니'님 본문의 프라퍼티 접근 예제입니다. 두줄만 발췌하죠. var obj = { "prop1" : "value1", "prop2" : "value2" }; alert( obj["prop1"] ); 행복한 고니 // 예시에 대해선 전혀 언급할 필요가 없지않나요? 님의 '객체가 {}로 만들어진다'를 저는 '{}로 객체가 표현된다'라고 말하고 있는 중이고, 결론적으로 이견이 아니라고 말씀드린게 제 마지막 커멘트입니다. 유일하게 다른 부분은... 저는 '{}'가 '연관배열표현'이라고 말씀드린 것입니다. 저또한 객체를 생성할때 JSON 및 다른 JS프레임웍과 혼용하기 위해 '{}' 를 즐겨쓰고 있습니다. (이부분에서 배열로 이해하는 것이 상당히 효과적입니다. 개인적으로... ^^) 실용론에 있어서는 다르지 않다는 뜻이지요. 다만 그 내면을 어떻게 보는가 하는 관점의 문제일 뿐입니다. 이만하면 된 것 아닐까요? ^^; 꾸벅~! ps; 객체가 연관배열이라고 볼 수 있는 근거는 '행복한고니'님 본문의 프라퍼티 접근 예제입니다. 두줄만 발췌하죠. var obj = { "prop1" : "value1", "prop2" : "value2" }; alert( obj["prop1"] );

행복한고니   07-03-24 15:32   낭망백수 // 저는 {}는 Object 이고 그냥 연관배열 처럼 보일뿐이라는 입장이라 {}가 연관배열 표현이라는 것에 동의를 못하고 있는겁니다. {}를 연관배열로 보시려면 new Object 로 생성된 것도 연관배열로 보셔야 합니다. 그냥 연관배열처럼 보일 뿐이고 두 가지는 같은 표현이며, Object 라는 것이 저의 주장입니다. 그래서 정확한 입장을 물어본겁니다. 1번이신가요, 2번이신가요? 아니면 다른 의견이신가요? P.S// var obj = new Object; obj["toString"] <- 이런 것도 됩니다. 따라서 객체로 보건, 연관배열로 보건 같이 봐야한다는 거죠. 낭망백수 // 저는 {}는 Object 이고 그냥 연관배열 처럼 보일뿐이라는 입장이라 {}가 연관배열 표현이라는 것에 동의를 못하고 있는겁니다. {}를 연관배열로 보시려면 new Object 로 생성된 것도 연관배열로 보셔야 합니다. 그냥 연관배열처럼 보일 뿐이고 두 가지는 같은 표현이며, Object 라는 것이 저의 주장입니다. 그래서 정확한 입장을 물어본겁니다. 1번이신가요, 2번이신가요? 아니면 다른 의견이신가요? P.S// var obj = new Object; obj["toString"] <- 이런 것도 됩니다. 따라서 객체로 보건, 연관배열로 보건 같이 봐야한다는 거죠.

숨어지내리   07-03-24 15:41   // 행복한 고니 참..ㅡㅡ; 그새 또 말과 주장이 바뀌어 버리셨네..ㅋ 이제 증명했더니 {} 가 object 의 instance 네요.. ㅋ " Object가 {} 에 의해 만들어진다 " 라고 까지 하셨는데.. ㅡㅡ; /////////////////////////////////////////////////////////////////////// var obj = new Object(); var obj= {}; 는 엄연히 다릅니다. 똑같다고 보시는것은 무리가 있습니다. ______________ 라고 했습니다. 그리고 두 가지가 다르다는 것을 보이기 위해서 다음과 같은 예제도 작성하셨죠. ______________ var obj = {}; alert(obj === new Object()); -> false ______________ 그런데, 이제와서 왜 갑자기 {} 와 Object를 비교하세요? 말을 번복하시는게 아니라면 일관성있게 주장해주세요. 저는 new Object와 {}가 같다는 입장이었으니까요. 누가 클래스와 인스턴스가 같다고 주장한답니까? Object 의 type은 function 이거든요? /////////////////////////////////////////////////////////////////////////////////////// 제가 말씀드리고 싶은 부분입니다.. 주장의 일관성 있는 부분 부탁드립니다. ㅡㅡ; "{} 와 Object 가 같고, [] 와 Array 가 같다는 의미입니다. " 이게 고니님의 주장이었습니다. 전 Object 와 같을수밖에 없는이유는 inherit 되었기 때문이다. 라고 말한거고요. 헌데 다시 instance 라고 말바꾸시는건 고니님인데요.. ㅡㅡ; 그리고 "제가 예로 든 내용도 문제가 있을테이지만, 행복한 고니님의 예제도 썩 좋아보이지 않습니다." 와 같이 말씀을 드려 문제가 있음을 말씀드렸는데도.. 그부분은 생략이시네요.ㅎ /////////////////////////// "{} 이게 new Object 를 실행한 것과 같은 결과를 리턴한다는데, 그 이상의 다른 말이 필요한지도 모르겠습니다. 그 어떤 문서에서도 {}과 new Object의 차이점을 본 적이 없는데, 무슨 상속을 왜 받은건가요? 표준 문서 어디에 상속이라는 내용이 나와있는지, Object literal 이라는 말이 다르게 해석될 수 있는 이유와 new Object 를 실행한 것과 같은 결과가 어떻게 중간에 상속이 되었다는 뜻으로 해석될 수 있는지와 같은 주장의 근거를 들어주세요" " 제 입장은 "new Object 와 {}은 같은 결과를 도출하고, 둘 다 Object의 인스턴스이다" 입니다.  " ////////////////////////// 아깐 위와 같이 상속된 부분을 증명해 보라더니.. ㅡㅡ; 제가 상속된 부분을 증명하기 위해서 비교를 한것이고요. alert(({})); alert(Object); 결국 위와 같이 상속된것을 증명했더니, 인스턴스이다라고 하신건가요? 그렇게 왔다갔다 하는건가요? .. 참... 깝깝합니다... "Object가 {} 에 의해 만들어진다" 라고 했는데.. 이젠 {} 는 Object 의 인스턴스이다? 참.. 깝깝합니다. /////////////////////////////////////////////////////////////////////////// 다시 한번 정리해드리자면, {}로 Object의 인스턴스를 생성할 수 있고, 이것은 new Object 와 같다는 것이 제 입장입니다. 본문에도 그렇게 썼구요. 하지만 님의 의견은 제 입장과는 분명히 달랐었죠. ______________ Object - {}           - Array ______________ 이것처럼 {}가 마치 Object와는 별개의 타입(연관배열이라고 하셨죠?)으로 구성된 것으로 말씀하셨었습니다. ///////////////////////////////////////////////////////////////////////////// 고니님의 주장은 인스턴스가 아니었습니다. 왜 상속얘기가 나오는지 도무지 이해할수 없다고 까지 하셨습니다. 그리고 제가 object 와는 별개의 타입이라고 한적은 없는것 같은데요. 연관배열형태라고 했지요.. ㅡㅡ; 형태(form)와 형(type)을 구분짓지 못하시군요.. ㅡㅡ; 주장을 바꾸시니, 참 토론이 무색하네요. " 자 이제, 이제 제가 보여드린 코드가 상속인지, 정말 object 와 같은지 보여드린것이니, 제가 문의한 고니님이 ECMA 문서에 표기된 Object가 {} 에 의해 만들어진다라는 표현을 알려주시고, 있다 없다 제대로 된 의사전달 해주시고, 있다면, 도대체 ECMA 문서의 몇번째라인부터인지 자세히 알려주십시요. " 이거나 알려주세요..ㅡㅡ; // 행복한 고니 참..ㅡㅡ; 그새 또 말과 주장이 바뀌어 버리셨네..ㅋ 이제 증명했더니 {} 가 object 의 instance 네요.. ㅋ " Object가 {} 에 의해 만들어진다 " 라고 까지 하셨는데.. ㅡㅡ; /////////////////////////////////////////////////////////////////////// var obj = new Object(); var obj= {}; 는 엄연히 다릅니다. 똑같다고 보시는것은 무리가 있습니다. ______________ 라고 했습니다. 그리고 두 가지가 다르다는 것을 보이기 위해서 다음과 같은 예제도 작성하셨죠. ______________ var obj = {}; alert(obj === new Object()); -> false ______________ 그런데, 이제와서 왜 갑자기 {} 와 Object를 비교하세요? 말을 번복하시는게 아니라면 일관성있게 주장해주세요. 저는 new Object와 {}가 같다는 입장이었으니까요. 누가 클래스와 인스턴스가 같다고 주장한답니까? Object 의 type은 function 이거든요? /////////////////////////////////////////////////////////////////////////////////////// 제가 말씀드리고 싶은 부분입니다.. 주장의 일관성 있는 부분 부탁드립니다. ㅡㅡ; "{} 와 Object 가 같고, [] 와 Array 가 같다는 의미입니다. " 이게 고니님의 주장이었습니다. 전 Object 와 같을수밖에 없는이유는 inherit 되었기 때문이다. 라고 말한거고요. 헌데 다시 instance 라고 말바꾸시는건 고니님인데요.. ㅡㅡ; 그리고 "제가 예로 든 내용도 문제가 있을테이지만, 행복한 고니님의 예제도 썩 좋아보이지 않습니다." 와 같이 말씀을 드려 문제가 있음을 말씀드렸는데도.. 그부분은 생략이시네요.ㅎ /////////////////////////// "{} 이게 new Object 를 실행한 것과 같은 결과를 리턴한다는데, 그 이상의 다른 말이 필요한지도 모르겠습니다. 그 어떤 문서에서도 {}과 new Object의 차이점을 본 적이 없는데, 무슨 상속을 왜 받은건가요? 표준 문서 어디에 상속이라는 내용이 나와있는지, Object literal 이라는 말이 다르게 해석될 수 있는 이유와 new Object 를 실행한 것과 같은 결과가 어떻게 중간에 상속이 되었다는 뜻으로 해석될 수 있는지와 같은 주장의 근거를 들어주세요" " 제 입장은 "new Object 와 {}은 같은 결과를 도출하고, 둘 다 Object의 인스턴스이다" 입니다. " ////////////////////////// 아깐 위와 같이 상속된 부분을 증명해 보라더니.. ㅡㅡ; 제가 상속된 부분을 증명하기 위해서 비교를 한것이고요. alert(({})); alert(Object); 결국 위와 같이 상속된것을 증명했더니, 인스턴스이다라고 하신건가요? 그렇게 왔다갔다 하는건가요? .. 참... 깝깝합니다... "Object가 {} 에 의해 만들어진다" 라고 했는데.. 이젠 {} 는 Object 의 인스턴스이다? 참.. 깝깝합니다. /////////////////////////////////////////////////////////////////////////// 다시 한번 정리해드리자면, {}로 Object의 인스턴스를 생성할 수 있고, 이것은 new Object 와 같다는 것이 제 입장입니다. 본문에도 그렇게 썼구요. 하지만 님의 의견은 제 입장과는 분명히 달랐었죠. ______________ Object - {} - Array ______________ 이것처럼 {}가 마치 Object와는 별개의 타입(연관배열이라고 하셨죠?)으로 구성된 것으로 말씀하셨었습니다. ///////////////////////////////////////////////////////////////////////////// 고니님의 주장은 인스턴스가 아니었습니다. 왜 상속얘기가 나오는지 도무지 이해할수 없다고 까지 하셨습니다. 그리고 제가 object 와는 별개의 타입이라고 한적은 없는것 같은데요. 연관배열형태라고 했지요.. ㅡㅡ; 형태(form)와 형(type)을 구분짓지 못하시군요.. ㅡㅡ; 주장을 바꾸시니, 참 토론이 무색하네요. " 자 이제, 이제 제가 보여드린 코드가 상속인지, 정말 object 와 같은지 보여드린것이니, 제가 문의한 고니님이 ECMA 문서에 표기된 Object가 {} 에 의해 만들어진다라는 표현을 알려주시고, 있다 없다 제대로 된 의사전달 해주시고, 있다면, 도대체 ECMA 문서의 몇번째라인부터인지 자세히 알려주십시요. " 이거나 알려주세요..ㅡㅡ;

행복한고니   07-03-24 15:48   숨어지내리 // 제 글 본문 보시라니까요. 제가 단 한번 오해가 있을만한 표현을 썼던 것은 인정하겠습니다. ______________________ {} 와 Object 가 같고, [] 와 Array 가 같다는 의미입니다. ______________________ 그럼 다른 글은 어때요? 다른 모든 글에서는 {}를 new Object 와 비교하고 있었는데요? 본문의 글도 Object 를 생성할 때라고 했습니다. 비록 제 표현에 문제가 있었을지라도 []과 같이 사용했기때문에 의미 정도는 파악했다고 생각했는데, 말꼬리를 잡자는 것도 아니고... 원... new Object와 {} 가 다르다면서요? 근데 이제 제가 말을 바꿨다고 하시는군요. ㅎㅎ 제가 처음에 썼던 표현이나 보세요. 낭망백수님의 글에 달았던 코멘트입니다. ______________________ 배열 비슷하게 표현된다고 해서 그게 배열인 것은 아닙니다. 연관배열처럼 보이는 Object type 입니다. var obj = new Object; 이 표현이나 var obj = {}; 이것은 똑같은 표현입니다. ______________________ 이래도 제가 말을 바꾼 건가요? 오해가 있을만한 글귀가 있었다고 말 꼬투리를 잡는 걸로 밖에 안보이네요. ㅎㅎ 표준문서에서 new Object 를 실행한 것과 같은 결과라는데 대체 어쩌다가 그게 내부적으로 상속된다라고 생각하셨을까요? 아니, 그 전에 말 바꾸는 것을 보니 이미 자신의 주장이 잘못된다는 사실을 아시는 것 같습니다. 더 이상은 말을 섞지 않아도 되겠군요. 쌩뚱맞게 클래스하고 인스턴스하고 비교해놓고 "내말이 맞지" 이러지 마시고요, 단 한번이라도 제대로 된 근거좀 가져오세요. ECMA를 못 믿겠다면 생성자가 같다는 사실은 어떻고 MDC에 있는 문서는 또 어때요? 제가 들었던 근거를 내버려두고서라도 코드상에서 모든 결과가 같다고 말하고 있는데, 혼자서만 다르다고 말하고 계시거든요? 그렇다면 다르다는 증거를 대는게 이치상 맞는 것 아닌지 생각해보게 되는군요. 아.. 그것도 이제는 애초에 했던 말을 바꾸셔서 클래스하고  인스턴스하고 다르다고 주장하고 계시더랬죠. 그 말은 맞습니다. 클래스하고 인스턴스하고 같다고 생각하는 사람이 어딨겠습니까. ㅎㅎ 숨어지내리 // 제 글 본문 보시라니까요. 제가 단 한번 오해가 있을만한 표현을 썼던 것은 인정하겠습니다. ______________________ {} 와 Object 가 같고, [] 와 Array 가 같다는 의미입니다. ______________________ 그럼 다른 글은 어때요? 다른 모든 글에서는 {}를 new Object 와 비교하고 있었는데요? 본문의 글도 Object 를 생성할 때라고 했습니다. 비록 제 표현에 문제가 있었을지라도 []과 같이 사용했기때문에 의미 정도는 파악했다고 생각했는데, 말꼬리를 잡자는 것도 아니고... 원... new Object와 {} 가 다르다면서요? 근데 이제 제가 말을 바꿨다고 하시는군요. ㅎㅎ 제가 처음에 썼던 표현이나 보세요. 낭망백수님의 글에 달았던 코멘트입니다. ______________________ 배열 비슷하게 표현된다고 해서 그게 배열인 것은 아닙니다. 연관배열처럼 보이는 Object type 입니다. var obj = new Object; 이 표현이나 var obj = {}; 이것은 똑같은 표현입니다. ______________________ 이래도 제가 말을 바꾼 건가요? 오해가 있을만한 글귀가 있었다고 말 꼬투리를 잡는 걸로 밖에 안보이네요. ㅎㅎ 표준문서에서 new Object 를 실행한 것과 같은 결과라는데 대체 어쩌다가 그게 내부적으로 상속된다라고 생각하셨을까요? 아니, 그 전에 말 바꾸는 것을 보니 이미 자신의 주장이 잘못된다는 사실을 아시는 것 같습니다. 더 이상은 말을 섞지 않아도 되겠군요. 쌩뚱맞게 클래스하고 인스턴스하고 비교해놓고 "내말이 맞지" 이러지 마시고요, 단 한번이라도 제대로 된 근거좀 가져오세요. ECMA를 못 믿겠다면 생성자가 같다는 사실은 어떻고 MDC에 있는 문서는 또 어때요? 제가 들었던 근거를 내버려두고서라도 코드상에서 모든 결과가 같다고 말하고 있는데, 혼자서만 다르다고 말하고 계시거든요? 그렇다면 다르다는 증거를 대는게 이치상 맞는 것 아닌지 생각해보게 되는군요. 아.. 그것도 이제는 애초에 했던 말을 바꾸셔서 클래스하고 인스턴스하고 다르다고 주장하고 계시더랬죠. 그 말은 맞습니다. 클래스하고 인스턴스하고 같다고 생각하는 사람이 어딨겠습니까. ㅎㅎ

숨어지내리   07-03-24 16:37   ^^; 참 알다가도 모르겠습니다. " Object가 {} 에 의해 만들어진다 " 라고 까지 하셨는데.. ㅡㅡ; 이렇게 까지 말씀하신 분이 말꼬리를 잡는다니.. ㅡㅡ; 누가 누구의 말꼬리를 잡는지 모르겠습니다. 표현이 똑같을지 모르지만, 내부적으로 다를수 있으니 똑같다고 말할수는 없을거 같다라는 의견을 내드렸는데,.. "그리고 Object 가 {} 으로 만들어진다는 말은 자바스크립트의 상위 스펙인 ECMA 표준문서에 있는 내용입니다. " 위와 같이 해박한 지식으로  말씀하시어 ECMA부분을 찾아봐도 이부분을 찾을수 없어, 어디부분인지 알려달라 했습니다. ㅡㅡ; Object 가 {} 에 의해 만들어진다는 말에 동의할수가 없었기 때문입니다. initializer 라는것은 알고 있습니다.. 헌데 Object 라는 놈이 {} 에 의해 만들어진다라는게 문서상에 있나해서 여쭙다가, 상속이 되어진것이라 생각한것이고, 그부분을 증명해달라 해서 증명해드렸더니. instance 다 라고 정리하시니.. 더이상 할말이 없네요 ^^; 그리고 제가 말씀드린 부분은 ECMA 문서에 없나봅니다? 답변이 없으신걸로 봐서는요..ㅡㅡ; ㅎㅎ 암튼.. 재미있는 토론이었습니다. ㅋ ^^; 참 알다가도 모르겠습니다. " Object가 {} 에 의해 만들어진다 " 라고 까지 하셨는데.. ㅡㅡ; 이렇게 까지 말씀하신 분이 말꼬리를 잡는다니.. ㅡㅡ; 누가 누구의 말꼬리를 잡는지 모르겠습니다. 표현이 똑같을지 모르지만, 내부적으로 다를수 있으니 똑같다고 말할수는 없을거 같다라는 의견을 내드렸는데,.. "그리고 Object 가 {} 으로 만들어진다는 말은 자바스크립트의 상위 스펙인 ECMA 표준문서에 있는 내용입니다. " 위와 같이 해박한 지식으로 말씀하시어 ECMA부분을 찾아봐도 이부분을 찾을수 없어, 어디부분인지 알려달라 했습니다. ㅡㅡ; Object 가 {} 에 의해 만들어진다는 말에 동의할수가 없었기 때문입니다. initializer 라는것은 알고 있습니다.. 헌데 Object 라는 놈이 {} 에 의해 만들어진다라는게 문서상에 있나해서 여쭙다가, 상속이 되어진것이라 생각한것이고, 그부분을 증명해달라 해서 증명해드렸더니. instance 다 라고 정리하시니.. 더이상 할말이 없네요 ^^; 그리고 제가 말씀드린 부분은 ECMA 문서에 없나봅니다? 답변이 없으신걸로 봐서는요..ㅡㅡ; ㅎㅎ 암튼.. 재미있는 토론이었습니다. ㅋ

행복한고니   07-03-24 16:57   숨어지내리 // 표현에 오해가 있을 수도 있음을 인정했는데도, 똑같은 것 밖에 물고늘어질게 없나보네요? 최초에 제가 했던 말과 최초에 님께서 했던 말을 잘 보세요 전 계속 그것에 관한 토론을 하고 있다고 생각했는데, 중간에 몇몇 부분에 제 표현에 오해가 있었다고 해서 최초의 주장이 사라져버리는건가요? ECMA에 왜 없다고 자꾸 물어보는지 알겠군요. Object 클래스 자체로 이해하고 있었군요. Object 가 생성된다는 의미를 저는 Object 객체가 생성된다라고 사용해왔고 코드를 통해 설명할 때는 분명 new Object 를 사용했었으며, 처음부터 지금까지 계속 같은 말만 하고 있습니다. 비록 표현에 오해가 있을 수 있다해도 말이죠. 그러니 그 부분을 자꾸 요구했던 것이로군요. 당연히 없을 수 밖에요. Object 는 이미 내장객체인데 그게 어떻게 {}으로 생성될 수 있겠습니까? 제 본문의 글을 본 사람중에 Object 타입 자체를 만들어낸다고 해석하신 분은 님밖에 없을 겁니다. 제가 작성한 코드 중 오해가 없을만한 코드 부분은 쏙 빼놓고, 적절하지 않았다고 했던 코드만을 예로 들고, 최초에 썼던 제 글에 대해서는 언급조차 안하고, 자신이 "연관배열이다"라고 말했던 부분은 어느새 온데간데 없고, 제 글을 보고나서 님께서 예로 든 코드에도 {} === new Object 가 있습니다. 이미 제 주장을 충분히 이해했다는 뜻인데도, 이제 와서 제 주장이 마치 달라졌다는 것처럼 말을 하는군요. 중간에 MC_BirdShim 님의 말씀도 저와 같은 말입니다. ____________________ 개인적인 느낌으로는 {}는 완전히 Object와 같던데요?. ____________________ 이 말이 설마 Object 라는 내장 객체 타입과 {}이 같다는 뜻이겠습니까? Object의 인스턴스가 {}와 같다는 의미죠. 단 한번도 자신의 주장은 근거조차 대지 못해놓고 이제와서 제 말에 오해가 있을만한 부분이 있으니 딱 걸렸다라고 생각하셨나보죠? 아니면 처음에는 이해했는데 갑자기 제 주장을 잘못 받아들이게 됐거나요. 토론은 커녕 시간낭비만 했군요. 연관배열에 대해서는 단 한번도 말씀하지 않더군요. ㅎㅎ 처음에 주장했던 연관배열은 어떻게 된건가요? ㅎㅎ 재밌네요. 어거지도 이만하면 상줄만 합니다. 쇼펜하우어의 논쟁에서 이기는 법을 마스터하셨군요. 이미 잘 알고 계시겠지만 링크걸어둡니다. http://jjowker.egloos.com/457219 숨어지내리 // 표현에 오해가 있을 수도 있음을 인정했는데도, 똑같은 것 밖에 물고늘어질게 없나보네요? 최초에 제가 했던 말과 최초에 님께서 했던 말을 잘 보세요 전 계속 그것에 관한 토론을 하고 있다고 생각했는데, 중간에 몇몇 부분에 제 표현에 오해가 있었다고 해서 최초의 주장이 사라져버리는건가요? ECMA에 왜 없다고 자꾸 물어보는지 알겠군요. Object 클래스 자체로 이해하고 있었군요. Object 가 생성된다는 의미를 저는 Object 객체가 생성된다라고 사용해왔고 코드를 통해 설명할 때는 분명 new Object 를 사용했었으며, 처음부터 지금까지 계속 같은 말만 하고 있습니다. 비록 표현에 오해가 있을 수 있다해도 말이죠. 그러니 그 부분을 자꾸 요구했던 것이로군요. 당연히 없을 수 밖에요. Object 는 이미 내장객체인데 그게 어떻게 {}으로 생성될 수 있겠습니까? 제 본문의 글을 본 사람중에 Object 타입 자체를 만들어낸다고 해석하신 분은 님밖에 없을 겁니다. 제가 작성한 코드 중 오해가 없을만한 코드 부분은 쏙 빼놓고, 적절하지 않았다고 했던 코드만을 예로 들고, 최초에 썼던 제 글에 대해서는 언급조차 안하고, 자신이 "연관배열이다"라고 말했던 부분은 어느새 온데간데 없고, 제 글을 보고나서 님께서 예로 든 코드에도 {} === new Object 가 있습니다. 이미 제 주장을 충분히 이해했다는 뜻인데도, 이제 와서 제 주장이 마치 달라졌다는 것처럼 말을 하는군요. 중간에 MC_BirdShim 님의 말씀도 저와 같은 말입니다. ____________________ 개인적인 느낌으로는 {}는 완전히 Object와 같던데요?. ____________________ 이 말이 설마 Object 라는 내장 객체 타입과 {}이 같다는 뜻이겠습니까? Object의 인스턴스가 {}와 같다는 의미죠. 단 한번도 자신의 주장은 근거조차 대지 못해놓고 이제와서 제 말에 오해가 있을만한 부분이 있으니 딱 걸렸다라고 생각하셨나보죠? 아니면 처음에는 이해했는데 갑자기 제 주장을 잘못 받아들이게 됐거나요. 토론은 커녕 시간낭비만 했군요. 연관배열에 대해서는 단 한번도 말씀하지 않더군요. ㅎㅎ 처음에 주장했던 연관배열은 어떻게 된건가요? ㅎㅎ 재밌네요. 어거지도 이만하면 상줄만 합니다. 쇼펜하우어의 논쟁에서 이기는 법을 마스터하셨군요. 이미 잘 알고 계시겠지만 링크걸어둡니다. http://jjowker.egloos.com/457219

maggot   07-03-24 17:21   뭐... 다 끝나가는 토론에 다시 불을 지피자는 건 아닙니다만, 제가 보기에도 Object() 와 {} 는 같은 표현같네요 링크거신 ecma spec 에도 {propertyName and Value} 는 Object() 로 object 인스턴스 생성하고 { 과 } 사이의 표현식을 해석해서 기생성된 object 인스턴스에 적용후 반환 하는 것으로 이해되구요 alert(({})) alert(Object) 로 비교할게 아니라 alert(({})) alert(Object()) 로 비교해야 맞다고 보여집니다 뭐... 다 끝나가는 토론에 다시 불을 지피자는 건 아닙니다만, 제가 보기에도 Object() 와 {} 는 같은 표현같네요 링크거신 ecma spec 에도 {propertyName and Value} 는 Object() 로 object 인스턴스 생성하고 { 과 } 사이의 표현식을 해석해서 기생성된 object 인스턴스에 적용후 반환 하는 것으로 이해되구요 alert(({})) alert(Object) 로 비교할게 아니라 alert(({})) alert(Object()) 로 비교해야 맞다고 보여집니다

숨어지내리   07-03-24 17:43   참 재미있는 히스토리입니다. ^^ ㅎㅎ 제가 예제를 잘못한것처럼 고니님도 예제를 잘못들어 놓으시고, ECMA 에 대한내용을 말씀하시니 Object 로 이해 되지 않을까요? ^^ 저만 그래서, 낭만백수님도 이러한 질문을 올린것일까요? 'Object 가 {} 으로 만들어진다'가 제가  정작 드리려는 말씀이었습니다. (물론 {} 로 연관배열이 만들어진다는 것도 동의하시리라 생각합니다.) 상속문제를 들먹이시더니, 이제는 제가 무지해서 앞뒤를 잘못해석한거였군요.^^ 말씀하신 주소는 고니님도 만만찮게 속하는 것 같습니다. ^^ㅎ 참 재미있는 히스토리입니다. ^^ ㅎㅎ 제가 예제를 잘못한것처럼 고니님도 예제를 잘못들어 놓으시고, ECMA 에 대한내용을 말씀하시니 Object 로 이해 되지 않을까요? ^^ 저만 그래서, 낭만백수님도 이러한 질문을 올린것일까요? 'Object 가 {} 으로 만들어진다'가 제가 정작 드리려는 말씀이었습니다. (물론 {} 로 연관배열이 만들어진다는 것도 동의하시리라 생각합니다.) 상속문제를 들먹이시더니, 이제는 제가 무지해서 앞뒤를 잘못해석한거였군요.^^ 말씀하신 주소는 고니님도 만만찮게 속하는 것 같습니다. ^^ㅎ

comefeel   07-03-24 18:05   maggot 님 끼지말아주세여 ; 여기서 마물 ㅤㄷㅙㅅ으면 합니다. maggot 님 끼지말아주세여 ; 여기서 마물 ㅤㄷㅙㅅ으면 합니다.

아리프리   07-03-22 13:17   호오 잘 보았습니다...감사드립니다. 호오 잘 보았습니다...감사드립니다.

드렁큰수달스   07-03-22 14:08   감사합니다 좋은 정보 얻어 갑니다. 감사합니다 좋은 정보 얻어 갑니다.

전진하는아르고   07-03-22 15:40   고니님 잘봤습니다. ^^ 얼마전 JSON 표기법을 공부하면서 JS 의 이상한 표현법을 보고 신기하다라고 생각했는데.. 이거 보니 새록새록하네요.. ㅎㅎ 고니님 잘봤습니다. ^^ 얼마전 JSON 표기법을 공부하면서 JS 의 이상한 표현법을 보고 신기하다라고 생각했는데.. 이거 보니 새록새록하네요.. ㅎㅎ

時建方進   07-03-22 17:06   잘봤슴당~감사요~ 잘봤슴당~감사요~

TP™ 아쿠아   07-03-23 23:11   열띤 토론듯. 열띤 토론듯.

행복한고니   07-03-24 16:58   토론이 아니었습니다 -_-;; 토론이 아니었습니다 -_-;;

숨어지내리   07-03-25 17:12   맞습니다.. ^^ 쇼팬하우어의 논쟁이었습니다. 고니님 말대로 상받으셔야 할듯합니다. http://jjowker.egloos.com/457219 맞습니다.. ^^ 쇼팬하우어의 논쟁이었습니다. 고니님 말대로 상받으셔야 할듯합니다. http://jjowker.egloos.com/457219

행복한고니   07-03-24 18:11   숨어지내리 // {} === new Object 이런 예제를 들었을 때부터 이미 제 주장을 이해해놓고서는 이제와서 말꼬리라니... 제 주장을 지금 말꼬리 잡는 식으로 이해했다면 이렇게 예제를 드셨겠죠. {} === Object 그 바로 아래쪽에서 적절하지 않다는 말은 제가 비교를 하려면 똑바로 하라며 비교대상이 될만한 예제를 들어준 것에 대해서 말씀하신게 아니던가요? 그 예제에서 제가 {} === Object 라고 하던가요? 제가 최초에 적었던 코멘트와 님께서 최초에 적었던 코멘트를 대비시켜드리죠. 처음이 제 것이고 그 다음이 님의 것입니다. 이 주장에 대해서는 적절하지 않거나 잘못되었다고 시인한 적이 단 한번도 없었죠. ------------------------------------------ var obj = new Object; 이 표현이나 var obj = {}; 이것은 똑같은 표현입니다. ------------------------------------------ var obj = new Object(); var obj= {}; 는 엄연히 다릅니다. 똑같다고 보시는것은 무리가 있습니다. ------------------------------------------ 저는 계속 이 두가지의 상반된 주장을 가지고 말하고 있다고 생각했는데, 이제와서 말꼬리군요. 인정할 건 인정하는게 자존심을 지키는 겁니다. 중간에 제가 오해할만한 표현이 있었다는 것은 인정하겠지만, 항상 제 의도는 var obj = new Object; 와 var obj = {}; 이것은 똑같은 표현이라는 것이었습니다. 두가지가 다르다는 주장을 할 게 아니라면 이쯤에서 그만 두십시오. 애쓰는 모습이 안쓰럽습니다. 숨어지내리 // {} === new Object 이런 예제를 들었을 때부터 이미 제 주장을 이해해놓고서는 이제와서 말꼬리라니... 제 주장을 지금 말꼬리 잡는 식으로 이해했다면 이렇게 예제를 드셨겠죠. {} === Object 그 바로 아래쪽에서 적절하지 않다는 말은 제가 비교를 하려면 똑바로 하라며 비교대상이 될만한 예제를 들어준 것에 대해서 말씀하신게 아니던가요? 그 예제에서 제가 {} === Object 라고 하던가요? 제가 최초에 적었던 코멘트와 님께서 최초에 적었던 코멘트를 대비시켜드리죠. 처음이 제 것이고 그 다음이 님의 것입니다. 이 주장에 대해서는 적절하지 않거나 잘못되었다고 시인한 적이 단 한번도 없었죠. ------------------------------------------ var obj = new Object; 이 표현이나 var obj = {}; 이것은 똑같은 표현입니다. ------------------------------------------ var obj = new Object(); var obj= {}; 는 엄연히 다릅니다. 똑같다고 보시는것은 무리가 있습니다. ------------------------------------------ 저는 계속 이 두가지의 상반된 주장을 가지고 말하고 있다고 생각했는데, 이제와서 말꼬리군요. 인정할 건 인정하는게 자존심을 지키는 겁니다. 중간에 제가 오해할만한 표현이 있었다는 것은 인정하겠지만, 항상 제 의도는 var obj = new Object; 와 var obj = {}; 이것은 똑같은 표현이라는 것이었습니다. 두가지가 다르다는 주장을 할 게 아니라면 이쯤에서 그만 두십시오. 애쓰는 모습이 안쓰럽습니다.

그네   07-03-24 21:42   재밌게 읽었습니다. 전 자바스크립트에 대해 거의 모릅니다. 대충 글을 읽어보고 개인적으로 정리해보니 이런거 같습니다. Object !== new object Object !== {} new object === {} new object 도 {} 도 instance 이니까요 {} 이 수행될때 상속을 하던 어땠건 간에 new object 동작을 하니깐요.. 라고요.. 그리고... 언어(대화형 언어) 선정에 조금은 신경을 쓰시는게 좋을거 같습니다. 이런 토론은 정말 필요하다고 생각이 듭니다만.. 표현방법에 문제가 조금 있지 않나...여겨집니다. 재밌게 읽었습니다. 전 자바스크립트에 대해 거의 모릅니다. 대충 글을 읽어보고 개인적으로 정리해보니 이런거 같습니다. Object !== new object Object !== {} new object === {} new object 도 {} 도 instance 이니까요 {} 이 수행될때 상속을 하던 어땠건 간에 new object 동작을 하니깐요.. 라고요.. 그리고... 언어(대화형 언어) 선정에 조금은 신경을 쓰시는게 좋을거 같습니다. 이런 토론은 정말 필요하다고 생각이 듭니다만.. 표현방법에 문제가 조금 있지 않나...여겨집니다.

낭망백수   07-03-25 00:32   행복한고니 // 누구나 다 똑같이 말하고 똑같은 매너로 대할 수는 없습니다. 좀 덜할 수는 있지만, 그렇다고 당신의 매너가 어떻다는 판단까지 이 자릴 통해 말씀하실 필요는 없어보입니다. '그만두십시오, 안쓰럽습니다' 는 좀 심하셨습니다. 꾸벅~! 행복한고니 // 누구나 다 똑같이 말하고 똑같은 매너로 대할 수는 없습니다. 좀 덜할 수는 있지만, 그렇다고 당신의 매너가 어떻다는 판단까지 이 자릴 통해 말씀하실 필요는 없어보입니다. '그만두십시오, 안쓰럽습니다' 는 좀 심하셨습니다. 꾸벅~!

간만이야   07-03-25 06:52   내가봐도 고니님 말씀이 좀 지나치신듯...  이런 좋은 정보에 이런 말다툼이라니 고수님들 좋은 모습을 보여주세요~ 내가봐도 고니님 말씀이 좀 지나치신듯... 이런 좋은 정보에 이런 말다툼이라니 고수님들 좋은 모습을 보여주세요~

숨어지내리   07-03-25 12:01   ^^; 안남기려고 했는데.. ㅎㅎ 다시 한번 제 입장에서 이해한 내용을 말씀 드리겠습니다. new Object() 와 {} 의 쓰임은 같겠지만, 내부적으로 다를수 있고, {} 의 쓰임이 연관배열로 많이들 표현하고, ECMA 문서에는 {} 은 new Object() 처럼 만들어진다고 있습니다. 제가 표현하려는 예제가 틀렸고, 마찬가지로 고니님의 예제도 틀린상태에서 해당부분에 대해 Object 가 {} 으로 만들어진다는내용은 없는데, 그렇게 말씀하셔서, 어느부분인지, 제가 알고 있기로는 상속의 개념에서 생각하고 있어서, 관련사항에 대해 그렇게 설명해 드렸습니다.  또한 {} 와 Object 는 같다라고 까지 하셨습니다... "MC_BirdShim  07-03-23 20:24  숨어지내리님 말씀은 Obejct를 Array,{}가 상속받았다는 뜻인가요?. []는 Array를 상속 받은 것이구요?. 내용 뜻을 잘 이해를 못 하겠어서 여쭙는 거였구요.. ^^;;  " 그래서 MC_BirdShim 님도 이렇게 이해하셨겠지요. 헌데, 내용에 대해 계속적인 반박으로 상속을 증명해 보라해서 답글을 남기게 된거고, Object 와 new Object() 를 이해를 잘못하고 계신게 아닌지 생각하고 있었습니다. 말씀하신 사항에 {} 가 Object의 인스턴스라고 하니, 문백을 보고 표현은 알아서 이해해야 되지 않는냐는 말씀에 다소 당황스러웠습니다. ^^;;; 그럼. "내가 JAVA 라고 얘기하는것에 대해 문맥을 보고 JAVASCRIPT 로 이해해야 되는게 아니냐? " 라는 말과 비슷한거라 보여서 입니다. 저만 Object 로 이해한건지.. 그래서 나중에는 new Object() 로 되어버린것인지.. 인격을 모독하는 부분에 대해서는 따로 언급하지는 않겠습니다. 다 자신이 쌓은 덕이니깐요. 일단, 제가 생각한 내용도 올려드린것이니 제가 잘못된 판단을 하여, 이렇게 긴 토론을 하게 되었다면 죄송한 말씀 올립니다. ^^ 전 올바르지 못한 내용으로 많은분들이 그게 정석이라 생각할까봐 그리 말씀드린것입니다. ^^ ^^; 안남기려고 했는데.. ㅎㅎ 다시 한번 제 입장에서 이해한 내용을 말씀 드리겠습니다. new Object() 와 {} 의 쓰임은 같겠지만, 내부적으로 다를수 있고, {} 의 쓰임이 연관배열로 많이들 표현하고, ECMA 문서에는 {} 은 new Object() 처럼 만들어진다고 있습니다. 제가 표현하려는 예제가 틀렸고, 마찬가지로 고니님의 예제도 틀린상태에서 해당부분에 대해 Object 가 {} 으로 만들어진다는내용은 없는데, 그렇게 말씀하셔서, 어느부분인지, 제가 알고 있기로는 상속의 개념에서 생각하고 있어서, 관련사항에 대해 그렇게 설명해 드렸습니다. 또한 {} 와 Object 는 같다라고 까지 하셨습니다... "MC_BirdShim 07-03-23 20:24 숨어지내리님 말씀은 Obejct를 Array,{}가 상속받았다는 뜻인가요?. []는 Array를 상속 받은 것이구요?. 내용 뜻을 잘 이해를 못 하겠어서 여쭙는 거였구요.. ^^;; " 그래서 MC_BirdShim 님도 이렇게 이해하셨겠지요. 헌데, 내용에 대해 계속적인 반박으로 상속을 증명해 보라해서 답글을 남기게 된거고, Object 와 new Object() 를 이해를 잘못하고 계신게 아닌지 생각하고 있었습니다. 말씀하신 사항에 {} 가 Object의 인스턴스라고 하니, 문백을 보고 표현은 알아서 이해해야 되지 않는냐는 말씀에 다소 당황스러웠습니다. ^^;;; 그럼. "내가 JAVA 라고 얘기하는것에 대해 문맥을 보고 JAVASCRIPT 로 이해해야 되는게 아니냐? " 라는 말과 비슷한거라 보여서 입니다. 저만 Object 로 이해한건지.. 그래서 나중에는 new Object() 로 되어버린것인지.. 인격을 모독하는 부분에 대해서는 따로 언급하지는 않겠습니다. 다 자신이 쌓은 덕이니깐요. 일단, 제가 생각한 내용도 올려드린것이니 제가 잘못된 판단을 하여, 이렇게 긴 토론을 하게 되었다면 죄송한 말씀 올립니다. ^^ 전 올바르지 못한 내용으로 많은분들이 그게 정석이라 생각할까봐 그리 말씀드린것입니다. ^^

행복한고니   07-03-25 14:10   답글 달까 말까 고민했는데, 아무래도 다는게 좋겠네요. 제가 인격수양이 덜되서 표현을 거칠고 생각없이 했던 것은 인정하며, 사과드립니다. 그리고 이 글은 별개의 문제로, -------------------------------------------------------------- 분명, 중간에 오해할만한 표현이 있었다고 말씀드렸습니다. 제 생각에 올바르지 못한 내용은 "{}은 연관배열이고 new Object 와는 다른 표현이다" 라고 하는 것입니다. 똑같은 의도로 잘 모르시는 분들이 봤을때 정말 다른 것이라고 생각할까봐 그리 장문의 글을 썼었죠. 제 글에 오해할만한 문장이 있었던 것은 인정하지만, 오해할만한 코드가 있었다고는 생각하지 않습니다. 제 글중 Object 라고만 표현한 많은 부분은 정확하게는 "Object 타입의 인스턴스"라고 표현해야 맞는 것도 사실입니다. 배열 객체를 생성할 때 배열을 만든다라고 하지, "배열타입의 인스턴스를 만든다"라고 표현하지 않는 것과 비슷한 정도로 생각했었습니다. 그리고, 충분히 이해하셨으며 그래서 진행중이라고 생각한거죠. 코드를 충분히 이해했다면 알만한 제 글이 오해를 받고 있다고는 미처 생각하지 못했습니다. 님께서 사용하신 표현, 상속. 상속이라고 하면, 흔히 타입간의 계층을 생각하게 마련입니다. 그래서, 상속이라는 표현이 마치 {}을 하나의 타입으로 보는 것처럼 보였으며, 님께서 썼던 최초의 코멘트를 생각할 때 충분히 그렇게 주장하고 있다고 생각할만 했습니다. MC_BirdShim 님의 말은 그런 겁니다. Array 가 타입인지 알고 있는데, {}과 Array가 Object 에서 상속받았다고 표현하셨으니까요. 그런데, 나중에 보면 인스턴스가 타입을 계승한 것도 상속이라고 표현하시는 것 같더군요. Array와 같이 {}를 두고 있음으로써, 마치 {}가 타입처럼 보이게 했다고 생각합니다. 다시한번 말씀드리지만, 저는 각자의 최초의 코멘트대로 {} 과 new Object 가 다른지/같은지에 대해서 계속 토론중이라고 생각했었습니다. 저의 처음 주장을 충분히 이해하시지 않았습니까? 그런데도 어째서 제가 갑자기 "Object 타입 자체를 {}로 만들 수 있다"고 했을 때, 짚고 넘어가지 않으셨는지 모르겠습니다. 어쨌거나 상관없습니다. 길고 긴 글들이 무의미하다는 것을 알았으니, 다시 처음의 논점으로 돌아가면 되니까요. 여전히 최초의 주장은 한번도 증명하지 못하셨음도 상기해주시기 바랍니다. 많은 분들이 잘못 생각할 것이 걱정되신다면 꼭 이 글에서가 아니더라도 님의 주장이 옳은지 틀린지는 증명해주셔야 할 것 같습니다. 사실, 제가 이토록 열을 냈던 이유가 "왜 자신의 주장은 증명하지 않고, 계속 다른 소리만 하고 있는가"라고 생각하게 되었기 때문이었습니다. 엔지니어는 말보다는 코드, 기술, 실력이라고 생각합니다. 하지만, 앞으로 이런 일이 있게되면 표현에도 주의를 기울이거나 중간중간 정리하는 과정이 필요하다는 것도 덕분에 알게되었습니다. P.S// 제 인격이 덜 된 것은 사실입니다. 그렇다고 자신의 잘못과 실수, 혹은 다른 사람이 오해할 수도 있는 부분을 단 한번도 언급하거나 인정하지 않은 분의 인격도 저에 비해서 대단히 훌륭하진 않은 것 같습니다. 제 표현이 거칠었던 점은 반성하지만, 그래도 남의 허물만 보는 것보다는 자신의 잘못을 인정하고 반성하는게 더 나은 자세라고 생각하고 있습니다. 답글 달까 말까 고민했는데, 아무래도 다는게 좋겠네요. 제가 인격수양이 덜되서 표현을 거칠고 생각없이 했던 것은 인정하며, 사과드립니다. 그리고 이 글은 별개의 문제로, -------------------------------------------------------------- 분명, 중간에 오해할만한 표현이 있었다고 말씀드렸습니다. 제 생각에 올바르지 못한 내용은 "{}은 연관배열이고 new Object 와는 다른 표현이다" 라고 하는 것입니다. 똑같은 의도로 잘 모르시는 분들이 봤을때 정말 다른 것이라고 생각할까봐 그리 장문의 글을 썼었죠. 제 글에 오해할만한 문장이 있었던 것은 인정하지만, 오해할만한 코드가 있었다고는 생각하지 않습니다. 제 글중 Object 라고만 표현한 많은 부분은 정확하게는 "Object 타입의 인스턴스"라고 표현해야 맞는 것도 사실입니다. 배열 객체를 생성할 때 배열을 만든다라고 하지, "배열타입의 인스턴스를 만든다"라고 표현하지 않는 것과 비슷한 정도로 생각했었습니다. 그리고, 충분히 이해하셨으며 그래서 진행중이라고 생각한거죠. 코드를 충분히 이해했다면 알만한 제 글이 오해를 받고 있다고는 미처 생각하지 못했습니다. 님께서 사용하신 표현, 상속. 상속이라고 하면, 흔히 타입간의 계층을 생각하게 마련입니다. 그래서, 상속이라는 표현이 마치 {}을 하나의 타입으로 보는 것처럼 보였으며, 님께서 썼던 최초의 코멘트를 생각할 때 충분히 그렇게 주장하고 있다고 생각할만 했습니다. MC_BirdShim 님의 말은 그런 겁니다. Array 가 타입인지 알고 있는데, {}과 Array가 Object 에서 상속받았다고 표현하셨으니까요. 그런데, 나중에 보면 인스턴스가 타입을 계승한 것도 상속이라고 표현하시는 것 같더군요. Array와 같이 {}를 두고 있음으로써, 마치 {}가 타입처럼 보이게 했다고 생각합니다. 다시한번 말씀드리지만, 저는 각자의 최초의 코멘트대로 {} 과 new Object 가 다른지/같은지에 대해서 계속 토론중이라고 생각했었습니다. 저의 처음 주장을 충분히 이해하시지 않았습니까? 그런데도 어째서 제가 갑자기 "Object 타입 자체를 {}로 만들 수 있다"고 했을 때, 짚고 넘어가지 않으셨는지 모르겠습니다. 어쨌거나 상관없습니다. 길고 긴 글들이 무의미하다는 것을 알았으니, 다시 처음의 논점으로 돌아가면 되니까요. 여전히 최초의 주장은 한번도 증명하지 못하셨음도 상기해주시기 바랍니다. 많은 분들이 잘못 생각할 것이 걱정되신다면 꼭 이 글에서가 아니더라도 님의 주장이 옳은지 틀린지는 증명해주셔야 할 것 같습니다. 사실, 제가 이토록 열을 냈던 이유가 "왜 자신의 주장은 증명하지 않고, 계속 다른 소리만 하고 있는가"라고 생각하게 되었기 때문이었습니다. 엔지니어는 말보다는 코드, 기술, 실력이라고 생각합니다. 하지만, 앞으로 이런 일이 있게되면 표현에도 주의를 기울이거나 중간중간 정리하는 과정이 필요하다는 것도 덕분에 알게되었습니다. P.S// 제 인격이 덜 된 것은 사실입니다. 그렇다고 자신의 잘못과 실수, 혹은 다른 사람이 오해할 수도 있는 부분을 단 한번도 언급하거나 인정하지 않은 분의 인격도 저에 비해서 대단히 훌륭하진 않은 것 같습니다. 제 표현이 거칠었던 점은 반성하지만, 그래도 남의 허물만 보는 것보다는 자신의 잘못을 인정하고 반성하는게 더 나은 자세라고 생각하고 있습니다.

숨어지내리   07-03-25 16:34   ..^^ 끝까지 가보자는 거군요.. new Object() 와 {} 의 쓰임새를 알려드립니다. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Defining_Getters_and_Setters 위의 내용을 보시고요. new Object() 와 {} 의 쓰임새를 제대로 파악해 보시기 바랍니다. You can define getters and setters on any predefined core object or user-defined object that supports the addition of new properties. The syntax for defining getters and setters uses the object literal syntax. 객체의 getters 와 setters 를 사용하기 위해서 literal syntax 를 사용한다고 나와있습니다. 결과가 같다고, 다 같은게 아니라고 그렇게 말을 해도 믿지 않고 책에 없다, 그런거 본적이 없다고 우기시는게 정말 재미있었습니다. 자꾸 허물 허물 하는데, 허물이 있으니 지적을 하지요.. ㅡㅡ; 솔직히 행복한 고니님이 많이 알고 해박한 지식이 있다는거 압니다만, 더 많이 알고, 더 잘하는 분들이 많고 지금도 저희의 논쟁을 보고 있을것이란 말입니다. "엔지니어는 말보다는 코드, 기술, 실력이라고 생각합니다" 위의 내용을 말씀하시는데에 저는 그것보다 노력이라 생각합니다. 코드 , 기술 , 실력 그 딴건 노력하면 다 됩니다. 평가를 받는것에 집중하시지 말고, 시시비비를 좋아하시지 말고, 한번정도는 남의 말에 귀기울일줄 아시는것도 배우셔야 할것 같습니다. 이만, 글을 끝냈으면 하는 바램입니다.  더 이상 행복한 고니님이 리플을 달아 불행한 고니님으로 안되시길 바랍니다. new Object() 와 {} 는 분명 차이가 있습니다. 결과가 core Object 를 밷는다고 해서 , 사용방법을 거스르고 사용하는것은 꽁수로 가는 지름길입니다. 큰길이 있으면, 큰길로 가시기 바랍니다. ps. 전 숨어서 지내렵니다. ㅡㅡ; 이제 여기서 종료.!! ok? (박해미버전) ps2. http://jjowker.egloos.com/457219 계속 이거 보고 있습니다. ㅡㅡ; 저도 많이 속하는데요 .. ㅎ ..^^ 끝까지 가보자는 거군요.. new Object() 와 {} 의 쓰임새를 알려드립니다. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Defining_Getters_and_Setters 위의 내용을 보시고요. new Object() 와 {} 의 쓰임새를 제대로 파악해 보시기 바랍니다. You can define getters and setters on any predefined core object or user-defined object that supports the addition of new properties. The syntax for defining getters and setters uses the object literal syntax. 객체의 getters 와 setters 를 사용하기 위해서 literal syntax 를 사용한다고 나와있습니다. 결과가 같다고, 다 같은게 아니라고 그렇게 말을 해도 믿지 않고 책에 없다, 그런거 본적이 없다고 우기시는게 정말 재미있었습니다. 자꾸 허물 허물 하는데, 허물이 있으니 지적을 하지요.. ㅡㅡ; 솔직히 행복한 고니님이 많이 알고 해박한 지식이 있다는거 압니다만, 더 많이 알고, 더 잘하는 분들이 많고 지금도 저희의 논쟁을 보고 있을것이란 말입니다. "엔지니어는 말보다는 코드, 기술, 실력이라고 생각합니다" 위의 내용을 말씀하시는데에 저는 그것보다 노력이라 생각합니다. 코드 , 기술 , 실력 그 딴건 노력하면 다 됩니다. 평가를 받는것에 집중하시지 말고, 시시비비를 좋아하시지 말고, 한번정도는 남의 말에 귀기울일줄 아시는것도 배우셔야 할것 같습니다. 이만, 글을 끝냈으면 하는 바램입니다. 더 이상 행복한 고니님이 리플을 달아 불행한 고니님으로 안되시길 바랍니다. new Object() 와 {} 는 분명 차이가 있습니다. 결과가 core Object 를 밷는다고 해서 , 사용방법을 거스르고 사용하는것은 꽁수로 가는 지름길입니다. 큰길이 있으면, 큰길로 가시기 바랍니다. ps. 전 숨어서 지내렵니다. ㅡㅡ; 이제 여기서 종료.!! ok? (박해미버전) ps2. http://jjowker.egloos.com/457219 계속 이거 보고 있습니다. ㅡㅡ; 저도 많이 속하는데요 .. ㅎ

행복한고니   07-03-25 17:45   아.. 드디어 원하는게 나왔군요. 처음부터 이렇게 나왔으면 좋을 뻔 했네요. 빨리 좀 이러시지 그러셨어요? 그랬으면 이런 소모적인 대화는 필요없었을텐데요. 근데, 근거가... 근거라고 볼 수가 없네요. 영문 해석은, setter와 getter를 정의하는데 object literal 이 사용된다입니다. 그렇다고 그게 new Object 로 되지 않으며, {} 와 new Object가 서로 다른 결과라는 것을 증명하지는 못하죠. 왜냐고요? new Object 로도 getter 와 setter 를 만들어 낼 수 있거든요. 님께서 주신 바로 그 링크 아래쪽에 있습니다. 물론, 잘 보고 주신거겠죠? var obj = new Object; var obj = {}; 의 모양이 다른 것처럼 말이죠... var obj = new Object; obj.__defineGetter__("year", function(){ return 2007 }); var obj = { get year() { return 2007 } }; 는 같은 거란 말입니다. 문법의 차이가 객체의 차이라고 말씀하실 건가요? 그건 아닐텐데 말이죠. 그나마도 getter, setter 는 IE에선 안되죠. 아쉽게도요. getter, setter 존재는 이미 알고 있던겁니다만, 그게 어째서 객체의 차이가 되는건지 모르겠네요. function a() {  alert('a');  } 와  var a = function() { alert('a'); } 는 다른 거라고 말씀하실 건가요? 제발요. 저를 설득할만한 근거를 "제.대.로" 좀 가지고 오세요. 그 긴 시간을 거쳐 가지고 온게 고작 이런겁니까? ECMA에서 new Object 를 실행한 것과 같은 결과를 리턴한다는게 제 근거였고, 모든 결과가 똑같다는게 제 근거였다면 그것을 반박할만한 증거를 가지고 오셔야죠. 전 정말 님의 말에 귀기울이고 있습니다. 그런데, 그 동안은 증거도 없이 주장만 하셨고, 지금 가져온게 겨우 이런거잖습니까? 증거도 근거도 없는 다른 사람의 주장을 제가 받아들일 수는 없는 노릇이죠. 근거도 없이 주장하는건 "우기는 것" 밖에 안됩니다. 지금 누구더러 우겼다고 하시는지 모르겠군요. 아닌 걸 아니라고 해놓고서 시시비비를 가리는 걸 좋아한다는 식으로 이상하게 만드시는군요. 저는 제 지식이 틀렸기를 진심으로 바라고 있습니다. 이렇게 긴 시간을 들였는데, 겨우 "알던 것의 재확인" 만 되면 저한테 뭐가 남겠습니까? 한번 쪽팔리고 지식을 배우는게 저한테는 오히려 이득인데 말이죠. 물론, 저보다 많이 아시는 분이 없을리가 있겠습니까. 그래서 더욱 알고 싶군요. 제가 알고 있는 제 지식이 틀렸다는 것을 증명해주시기를 정말 기다리고 있습니다. 자, 제가 다시 new Object 와 {}은 똑같다고 말했습니다. 모양이 다르다고 내부적으로 달라지는 것은 아니라고 말씀드렸습니다. {}은 ECMA문서에서도 그랬습니다. new Object 로 객체 만들고 property 설정하는 것과 같은 결과라고요. 그러니 모양이 다르다고 객체 자체가 다른 것은 아니라는 말입니다. "new Object" 로 표현을 실행한 것과 같은 결과를 도출한다고 그랬으니까요. P.S// 전 논쟁하는 것보다 배우는 것을 훨씬 좋아합니다. 또한 검증되지 않은 지식을 가지고 있는 것도 아주 싫어합니다. 그래서 제 지식의 옳고 그름을 알고 싶어하는거죠. 그래서 제 지식에는 "제가 검증해본 것"과 "남이 그렇다고 한 것"으로 나누어져 있습니다. 이 경우에는 "남이 그렇다고 한 것"이 "제가 검증해본 것"과 상충되기 때문에 논쟁이 되었죠. P.S2// 그나저나 setter, getter 덕분에 {}이 연관배열 표현이라는 주장은 더 설득력을 잃겠는데요? 아.. 드디어 원하는게 나왔군요. 처음부터 이렇게 나왔으면 좋을 뻔 했네요. 빨리 좀 이러시지 그러셨어요? 그랬으면 이런 소모적인 대화는 필요없었을텐데요. 근데, 근거가... 근거라고 볼 수가 없네요. 영문 해석은, setter와 getter를 정의하는데 object literal 이 사용된다입니다. 그렇다고 그게 new Object 로 되지 않으며, {} 와 new Object가 서로 다른 결과라는 것을 증명하지는 못하죠. 왜냐고요? new Object 로도 getter 와 setter 를 만들어 낼 수 있거든요. 님께서 주신 바로 그 링크 아래쪽에 있습니다. 물론, 잘 보고 주신거겠죠? var obj = new Object; var obj = {}; 의 모양이 다른 것처럼 말이죠... var obj = new Object; obj.__defineGetter__("year", function(){ return 2007 }); var obj = { get year() { return 2007 } }; 는 같은 거란 말입니다. 문법의 차이가 객체의 차이라고 말씀하실 건가요? 그건 아닐텐데 말이죠. 그나마도 getter, setter 는 IE에선 안되죠. 아쉽게도요. getter, setter 존재는 이미 알고 있던겁니다만, 그게 어째서 객체의 차이가 되는건지 모르겠네요. function a() { alert('a'); } 와 var a = function() { alert('a'); } 는 다른 거라고 말씀하실 건가요? 제발요. 저를 설득할만한 근거를 "제.대.로" 좀 가지고 오세요. 그 긴 시간을 거쳐 가지고 온게 고작 이런겁니까? ECMA에서 new Object 를 실행한 것과 같은 결과를 리턴한다는게 제 근거였고, 모든 결과가 똑같다는게 제 근거였다면 그것을 반박할만한 증거를 가지고 오셔야죠. 전 정말 님의 말에 귀기울이고 있습니다. 그런데, 그 동안은 증거도 없이 주장만 하셨고, 지금 가져온게 겨우 이런거잖습니까? 증거도 근거도 없는 다른 사람의 주장을 제가 받아들일 수는 없는 노릇이죠. 근거도 없이 주장하는건 "우기는 것" 밖에 안됩니다. 지금 누구더러 우겼다고 하시는지 모르겠군요. 아닌 걸 아니라고 해놓고서 시시비비를 가리는 걸 좋아한다는 식으로 이상하게 만드시는군요. 저는 제 지식이 틀렸기를 진심으로 바라고 있습니다. 이렇게 긴 시간을 들였는데, 겨우 "알던 것의 재확인" 만 되면 저한테 뭐가 남겠습니까? 한번 쪽팔리고 지식을 배우는게 저한테는 오히려 이득인데 말이죠. 물론, 저보다 많이 아시는 분이 없을리가 있겠습니까. 그래서 더욱 알고 싶군요. 제가 알고 있는 제 지식이 틀렸다는 것을 증명해주시기를 정말 기다리고 있습니다. 자, 제가 다시 new Object 와 {}은 똑같다고 말했습니다. 모양이 다르다고 내부적으로 달라지는 것은 아니라고 말씀드렸습니다. {}은 ECMA문서에서도 그랬습니다. new Object 로 객체 만들고 property 설정하는 것과 같은 결과라고요. 그러니 모양이 다르다고 객체 자체가 다른 것은 아니라는 말입니다. "new Object" 로 표현을 실행한 것과 같은 결과를 도출한다고 그랬으니까요. P.S// 전 논쟁하는 것보다 배우는 것을 훨씬 좋아합니다. 또한 검증되지 않은 지식을 가지고 있는 것도 아주 싫어합니다. 그래서 제 지식의 옳고 그름을 알고 싶어하는거죠. 그래서 제 지식에는 "제가 검증해본 것"과 "남이 그렇다고 한 것"으로 나누어져 있습니다. 이 경우에는 "남이 그렇다고 한 것"이 "제가 검증해본 것"과 상충되기 때문에 논쟁이 되었죠. P.S2// 그나저나 setter, getter 덕분에 {}이 연관배열 표현이라는 주장은 더 설득력을 잃겠는데요?

숨어지내리   07-03-25 18:13   ..^^ 끝까지 불행한 고니님으로 가실 모양입니다. 쪽지까지 주시고요.. Summary In principle, getters and setters can be either defined using object initializers, or added later to any object at any time using a getter or setter adding method. When defining getters and setters using object initializers all you need to do is to prefix a getter method with get and a setter method with set. Of course, the getter method must not expect a parameter, while the setter method expects exactly one parameter (the new value to set). For instance: 고니님 말대로 setter 와 getter 는 2가지로 만들수 있는건 사실입니다. When defining getters and setters using object initializers all you need to do is to prefix a getter method with get and a setter method with set 허나, setter 와 getter 를 preifx 시키기 위해 object initializers 를 사용한다 되어 있습니다. 그리고 new Object() 선언할때 , setter 와 getter 는 만들수 없습니다. ㅡㅡ; added later to any object at any time using 이죠.. ㅡㅡ; 본질은 다르다는 겁니다.. 우기시지 마시고, 영어를 차근히 해석하세요. 쇼팬하우어의 상을 두번받으셔야 겠습니다.  http://jjowker.egloos.com/457219  http://jjowker.egloos.com/457219 http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Literals#Object_Literals An object literal is a list of zero or more pairs of property names and associated values of an object, enclosed in curly braces ({}). 위에서도 속성값과 연관값을 쌍으로 갖는 object 로 표현하고 있습니다. ㅡㅡ; 그러니 연관배열형태라고 말하게 되는것이고요.. 더이상 시간 낭비 맙시다... 불행한 고니씨. 인정하셨다면, 죄송하다고 하는것도 예의입니다. ㅡㅡ; ..^^ 끝까지 불행한 고니님으로 가실 모양입니다. 쪽지까지 주시고요.. Summary In principle, getters and setters can be either defined using object initializers, or added later to any object at any time using a getter or setter adding method. When defining getters and setters using object initializers all you need to do is to prefix a getter method with get and a setter method with set. Of course, the getter method must not expect a parameter, while the setter method expects exactly one parameter (the new value to set). For instance: 고니님 말대로 setter 와 getter 는 2가지로 만들수 있는건 사실입니다. When defining getters and setters using object initializers all you need to do is to prefix a getter method with get and a setter method with set 허나, setter 와 getter 를 preifx 시키기 위해 object initializers 를 사용한다 되어 있습니다. 그리고 new Object() 선언할때 , setter 와 getter 는 만들수 없습니다. ㅡㅡ; added later to any object at any time using 이죠.. ㅡㅡ; 본질은 다르다는 겁니다.. 우기시지 마시고, 영어를 차근히 해석하세요. 쇼팬하우어의 상을 두번받으셔야 겠습니다. http://jjowker.egloos.com/457219 http://jjowker.egloos.com/457219 http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Literals#Object_Literals An object literal is a list of zero or more pairs of property names and associated values of an object, enclosed in curly braces ({}). 위에서도 속성값과 연관값을 쌍으로 갖는 object 로 표현하고 있습니다. ㅡㅡ; 그러니 연관배열형태라고 말하게 되는것이고요.. 더이상 시간 낭비 맙시다... 불행한 고니씨. 인정하셨다면, 죄송하다고 하는것도 예의입니다. ㅡㅡ;

행복한고니   07-03-25 18:41   그런 식으로 할꺼면, getter, setter 까지 가지 않아도 이미 {propertyName:value} 역시 마찬가지입니다. new Object에서는 값을 설정하지 못하니까요. 하지만, 분명 ECMA 표준 문서에서는 같은 결과라고 얘기하고 있습니다. getter, setter 가 선언될 때 그렇게 설정이 되는 것은 {} 문법이 말 그대로 Object initializer 라서지, 그게 new Object 와 {}가 다르다는 근거는 되지 못한다는 겁니다. Object literal 에 대해서는 이미 사용법이 다르다고 얘기하지 않았습니까? 그것을 ECMA 문서에서도 new Object 를 실행한 것과 같은 결과를 도출한다고 했고요. 지금 님께서는 "모양이 다르고 사용법이 다르니 객체가 다르다" 라고 말씀하고 계신겁니다. 영어는 매우 차근차근 읽었고요, 참고로, MDC에서 한국어 번역자로도 활동하고 있어서, MDC 문서는 적잖게 읽었습니다. 특히, JavaScript에 관한 문서는 꽤 많이 읽었거든요. 주신 링크들도 안 읽고 이런말하는게 아닙니다. 선언할 때 그렇게 설정할 수 있는 것은 "문법적인 특징일 뿐" 이라는게 제가 생각하는 바인 것입니다. 내부적으로 다르다는 근거를 아직도 못가져 오셨잖습니까? 같다는 근거라면 제가 더 들어드릴 수는 있습니다만...? alert( ({}).__proto__ == Object.prototype ); alert( (new Object).__proto__ == Object.prototype ); alert( (new Array).__proto__ == Object.prototype ); __proto__ 에 대해서는 http://livedocs.adobe.com/flashlite/2_kr/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000731.html 이 링크 참고하세요. 어떤 객체로부터 만들어졌는지 알 수 있는 겁니다. 세번째 new Array를 예로 든 것은 {}과 new Object 는 같으나 new Array와는 다르다는 것을 보여주기 위해서입니다. 이런 토론이 시작되게 된 데에는 new Object 와 {}가 다르다는 말씀을 하셨기 때문이고, 그 아래에 {}은 연관배열이라고 하셨기 때문입니다. 그 주장이 맞으려면 new Object 와 {}은 다르며, {}이 연관배열이어야 하는데, 여전히 {}과 new Object 가 다르다는 근거를 들지 못하고 계십니다. 문법적인 차이는 이미 있다고 말씀드렸습니다만, 그게 내부적으로 다르다는 근거는 되지 못한다고도 말씀드렸습니다. 제발, 근거를 제대로 좀 가져오세요... _________________________________________ 혹시 또 오해가 있을지 모르니 입장을 한번 밝혀봅시다. 1. {}으로 생성된 인스턴스는 new Object 로 생성된 인스턴스와 같은 인스턴스입니까 아니면 다른 종류의 인스턴스입니까? (identity 가 아닌 equality 를 묻는 겁니다) -> 제 입장은 같은 값을 가지는 인스턴스라고 봅니다. 2. {}의 모양이 다르다고, {}과 new Object는 다른 건가요? 그렇다면 []와 new Array는 같은 걸까요, 다른 걸까요? var a  = function(){ alert('a'); } 와 var a = new Function("alert('a') "); 는 같은 걸까요, 다른 걸까요? -> 제 입장은 예로 들었던 것들은 서로 같은 값을 가진다입니다. _________________________________________ 분명 System 상에서 구현되어져 나온다고 그러셨는데, 문법이 alias 된 것이 객체 자체가 다르다는 것을 증명해주는 것은 못됩니다. 다시 부탁드립니다. (__) P.S// 글을 조금 수정하셨네요. 마지막 말은 저도 그대로 돌려드립니다. 그런 식으로 할꺼면, getter, setter 까지 가지 않아도 이미 {propertyName:value} 역시 마찬가지입니다. new Object에서는 값을 설정하지 못하니까요. 하지만, 분명 ECMA 표준 문서에서는 같은 결과라고 얘기하고 있습니다. getter, setter 가 선언될 때 그렇게 설정이 되는 것은 {} 문법이 말 그대로 Object initializer 라서지, 그게 new Object 와 {}가 다르다는 근거는 되지 못한다는 겁니다. Object literal 에 대해서는 이미 사용법이 다르다고 얘기하지 않았습니까? 그것을 ECMA 문서에서도 new Object 를 실행한 것과 같은 결과를 도출한다고 했고요. 지금 님께서는 "모양이 다르고 사용법이 다르니 객체가 다르다" 라고 말씀하고 계신겁니다. 영어는 매우 차근차근 읽었고요, 참고로, MDC에서 한국어 번역자로도 활동하고 있어서, MDC 문서는 적잖게 읽었습니다. 특히, JavaScript에 관한 문서는 꽤 많이 읽었거든요. 주신 링크들도 안 읽고 이런말하는게 아닙니다. 선언할 때 그렇게 설정할 수 있는 것은 "문법적인 특징일 뿐" 이라는게 제가 생각하는 바인 것입니다. 내부적으로 다르다는 근거를 아직도 못가져 오셨잖습니까? 같다는 근거라면 제가 더 들어드릴 수는 있습니다만...? alert( ({}).__proto__ == Object.prototype ); alert( (new Object).__proto__ == Object.prototype ); alert( (new Array).__proto__ == Object.prototype ); __proto__ 에 대해서는 http://livedocs.adobe.com/flashlite/2_kr/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000731.html 이 링크 참고하세요. 어떤 객체로부터 만들어졌는지 알 수 있는 겁니다. 세번째 new Array를 예로 든 것은 {}과 new Object 는 같으나 new Array와는 다르다는 것을 보여주기 위해서입니다. 이런 토론이 시작되게 된 데에는 new Object 와 {}가 다르다는 말씀을 하셨기 때문이고, 그 아래에 {}은 연관배열이라고 하셨기 때문입니다. 그 주장이 맞으려면 new Object 와 {}은 다르며, {}이 연관배열이어야 하는데, 여전히 {}과 new Object 가 다르다는 근거를 들지 못하고 계십니다. 문법적인 차이는 이미 있다고 말씀드렸습니다만, 그게 내부적으로 다르다는 근거는 되지 못한다고도 말씀드렸습니다. 제발, 근거를 제대로 좀 가져오세요... _________________________________________ 혹시 또 오해가 있을지 모르니 입장을 한번 밝혀봅시다. 1. {}으로 생성된 인스턴스는 new Object 로 생성된 인스턴스와 같은 인스턴스입니까 아니면 다른 종류의 인스턴스입니까? (identity 가 아닌 equality 를 묻는 겁니다) -> 제 입장은 같은 값을 가지는 인스턴스라고 봅니다. 2. {}의 모양이 다르다고, {}과 new Object는 다른 건가요? 그렇다면 []와 new Array는 같은 걸까요, 다른 걸까요? var a = function(){ alert('a'); } 와 var a = new Function("alert('a') "); 는 같은 걸까요, 다른 걸까요? -> 제 입장은 예로 들었던 것들은 서로 같은 값을 가진다입니다. _________________________________________ 분명 System 상에서 구현되어져 나온다고 그러셨는데, 문법이 alias 된 것이 객체 자체가 다르다는 것을 증명해주는 것은 못됩니다. 다시 부탁드립니다. (__) P.S// 글을 조금 수정하셨네요. 마지막 말은 저도 그대로 돌려드립니다.

숨어지내리   07-03-25 18:45   그냥.. 제가 졌습니다. ^^; 본질을 흐리시군요. 먼가를 답을 내주면 다른 소리 하고.. 쇼팬하우어의 상 3번 받으시고, 그렇게 new Object() 와 {} 는 똑같다라고 생각하시면 될듯합니다.  http://jjowker.egloos.com/457219  http://jjowker.egloos.com/457219  http://jjowker.egloos.com/457219 그냥.. 제가 졌습니다. ^^; 본질을 흐리시군요. 먼가를 답을 내주면 다른 소리 하고.. 쇼팬하우어의 상 3번 받으시고, 그렇게 new Object() 와 {} 는 똑같다라고 생각하시면 될듯합니다. http://jjowker.egloos.com/457219 http://jjowker.egloos.com/457219 http://jjowker.egloos.com/457219

행복한고니   07-03-25 18:47   아뇨. 정말로 틀렸다는 것을 증명해주시기를 바라고 있습니다. 원하신다면 문서로 만들어서 대중의 심판을 받을 각오도 되어있습니다. 여태까지 주신 근거는 제가 아니라고 반박해드렸습니다. 애매한 태도로 제가 우긴 것처럼 하지 마시고요, 정확하게 논거를 들어주시기 바랍니다. 틀렸으면 깨끗이 인정을 하시던가 그렇지 않으면 "내부적으로는 다르다" 는 것에 대한 증거를 보여주셨으면 합니다. 지금과 같은 태도는 별로 바람직하지 않다고 봅니다. 본질을 흐렸다고 생각하지 않고 있는데, 본질은 무엇이며 어떻게 흐렸는지도 좀 알려주시고요. 인정하기 싫으신건지는 모르겠지만, 어쨌든 간곡히 부탁드립니다. 아뇨. 정말로 틀렸다는 것을 증명해주시기를 바라고 있습니다. 원하신다면 문서로 만들어서 대중의 심판을 받을 각오도 되어있습니다. 여태까지 주신 근거는 제가 아니라고 반박해드렸습니다. 애매한 태도로 제가 우긴 것처럼 하지 마시고요, 정확하게 논거를 들어주시기 바랍니다. 틀렸으면 깨끗이 인정을 하시던가 그렇지 않으면 "내부적으로는 다르다" 는 것에 대한 증거를 보여주셨으면 합니다. 지금과 같은 태도는 별로 바람직하지 않다고 봅니다. 본질을 흐렸다고 생각하지 않고 있는데, 본질은 무엇이며 어떻게 흐렸는지도 좀 알려주시고요. 인정하기 싫으신건지는 모르겠지만, 어쨌든 간곡히 부탁드립니다.

행복한고니   07-03-25 19:09   String literal 과 String object 는 서로 다른 거라는 근거는 찾았습니다. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Predefined_Core_Objects:String_Object eval 을 하면 결과가 다르다는군요. 제가 예로 들었었는데, 그 부분은 제가 틀렸습니다. "" 과 new String 은 서로 다릅니다. 그런데, 아직도 Object literal 과 Object object 가 서로 다른 거라는 근거는 못찾겠네요. 알고 계시다면 제발 좀 알려주세요. String literal 과 String object 는 서로 다른 거라는 근거는 찾았습니다. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Predefined_Core_Objects:String_Object eval 을 하면 결과가 다르다는군요. 제가 예로 들었었는데, 그 부분은 제가 틀렸습니다. "" 과 new String 은 서로 다릅니다. 그런데, 아직도 Object literal 과 Object object 가 서로 다른 거라는 근거는 못찾겠네요. 알고 계시다면 제발 좀 알려주세요.

숨어지내리   07-03-25 19:16   http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Defining_Getters_and_Setters 문서에 나와 있는데로, new Object 와 {} 의 차이점이 설명되어 있는데, 더이상 어떤걸 증명하라는건지 이해가 되질 않는군요. 제가 지치니, 해야할 일도 못하고 있군요.. 가뜩이나 휴일에 나와서 일하는데.. ㅠㅠ 아까도 말씀하신 논쟁도 아닌 소모전으로 가시지 말고, 문서에 나와 있는대로 동작하니, http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Using_Object_Initializers 의 If an object is created with an object initializer in a top-level script, JavaScript interprets the object each time it evaluates an expression containing the object literal. In addition, an initializer used in a function is created each time the function is called. 위의 내용을 해석하시면 될듯 합니다. 또한 http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Literals#Object_Literals This will lead to an error or not behave as you expect, because the { will be interpreted as the beginning of a block. 이 부분도 잘 생각해 보시기 바랍니다. 왜 에러가 나고, 원하는 대로 동작하지 않는지를.. 이제 더이상 저에게 묻지 마시고, 문서를 보세요.. 머리아픕니다.. 해야할일도 산더미인데.. ㅡㅡ; 보시고, 인정하시면 그동안 무례하게 한 부분 사과 해 주시면 감사하겠습니다. 사과를 안하시면 쇼팬하우어 상 100번 드립니다. ㅡㅡ;;;;;; for( var i = 0 ; i < 100 ; ++i){ 행복한고니 = "http://jjowker.egloos.com/457219"; } 불행한 고니라고 부르고 다니겠습니다. ㅡㅡ; (반협박이죠.. ^^) 그럼 저도 사과하도록 하겠습니다. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Defining_Getters_and_Setters 문서에 나와 있는데로, new Object 와 {} 의 차이점이 설명되어 있는데, 더이상 어떤걸 증명하라는건지 이해가 되질 않는군요. 제가 지치니, 해야할 일도 못하고 있군요.. 가뜩이나 휴일에 나와서 일하는데.. ㅠㅠ 아까도 말씀하신 논쟁도 아닌 소모전으로 가시지 말고, 문서에 나와 있는대로 동작하니, http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Using_Object_Initializers 의 If an object is created with an object initializer in a top-level script, JavaScript interprets the object each time it evaluates an expression containing the object literal. In addition, an initializer used in a function is created each time the function is called. 위의 내용을 해석하시면 될듯 합니다. 또한 http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Literals#Object_Literals This will lead to an error or not behave as you expect, because the { will be interpreted as the beginning of a block. 이 부분도 잘 생각해 보시기 바랍니다. 왜 에러가 나고, 원하는 대로 동작하지 않는지를.. 이제 더이상 저에게 묻지 마시고, 문서를 보세요.. 머리아픕니다.. 해야할일도 산더미인데.. ㅡㅡ; 보시고, 인정하시면 그동안 무례하게 한 부분 사과 해 주시면 감사하겠습니다. 사과를 안하시면 쇼팬하우어 상 100번 드립니다. ㅡㅡ;;;;;; for( var i = 0 ; i < 100 ; ++i){ 행복한고니 = "http://jjowker.egloos.com/457219"; } 불행한 고니라고 부르고 다니겠습니다. ㅡㅡ; (반협박이죠.. ^^) 그럼 저도 사과하도록 하겠습니다.

행복한고니   07-03-25 19:51   문서에 나와있는 걸로는 "문법적인 차이" 외에는 아무리 봐도 알 수가 없네요. 구체적으로 어디에 집중해서 봐야하는건가요? 작동하는 방식은 이미 다르다고 말씀드렸고요. 그게 내부적으로 다르다는 근거는 되지 않는다고 말씀도 이미 수차례 드렸습니다. 생긴 모양이 그렇게 보일 뿐 new Object 로 객체 생성하고 프로퍼티 붙이는 것과 다를 게 없다고도 말씀드렸고요. 던져주신 문서만 보고 이해하려 해도 대체 무슨 의도로 주신건지 이해가 안됩니다. 제가 부족하다면 정확하게 찍어주시고 예제도 부탁합니다. 정확히 어디를 보면 되나요? 영문 해석을 보면 object 가 evaluate 될 때마다 literal 안에 있는 문장이 해석된다 라고 하는데요, evaluate 된다는 것은 선언될 때를 말하는 걸로 보이는군요. 그건 당연한거라고 보고요. 함수안에서 사용된 initializer 는 함수가 호출될 때마다 선언된다고 하는데, 함수안에서 사용되었으면 당연한겁니다. 또한, 그 챕터의 다른 예제에서는 function car(){} 와 같은 식으로 흔히 말하는 OOP 적인 사용을 설명하고 있고요. 챕터 자체에서 사용된 Objects라는 단어가 우리가 논하고 있는 코어 Object가 아닌 각각의 객체들을 얘기하고 있습니다.  new Object 와의 차이점이 아닌 function car() 를 정의하고 new Car() 를 사용하는 것과의 차이점을 설명하는 겁니다. 저 문장을 그냥 던져주신게 아닐텐데, 어떤 걸 보라고 주신건가요? new Object 와 {}간에는 어떤 차이가 있는 건가요? 가능하다면 예제도 하나 주시고요. 두번째에서,  에러는.. 제가 예제를 들 때 괄호로 감싸는 이유입니다. {}를 문법적으로 블럭의 시작으로 보기때문에 에러를 발생시키거든요(문서에도 그렇게 나왔죠). 이것은 {}가 객체를 생성하는 용도의 Object initializer 말고도 다른 용도(with, for, function 등을 정의할 때)로도 사용되기 때문에 인터프리터가 혼동을 일으키는 것에 불과합니다. 그래서, 제가 예제로 드릴 때 마다 항상 ({}) 과 같이 괄호로 감싸서 드렸잖습니까. 문법과 사용법이 다른게 어째서 내부적으로 다르다는 증거가 되는지를 묻는겁니다. ""과 new String 은 제가 찾은 것이긴 하지만 아주 쉽게 수긍했습니다. eval의 결과가 달랐으니, 두가지가 서로 다르다는 증거가 되는거죠. 하지만 여전히 {}과 new Object는 수긍이 안되는군요. P.S// 제가 무례하게 한 부분은 단어 선정이 과격했던 것 말고는 없다고 생각하는군요. 그리고 그 부분은 지나쳤다고 이미 사과했습니다. 불행하다고 부르셨던 것은 그냥 넘어가드리겠습니다. 문서에 나와있는 걸로는 "문법적인 차이" 외에는 아무리 봐도 알 수가 없네요. 구체적으로 어디에 집중해서 봐야하는건가요? 작동하는 방식은 이미 다르다고 말씀드렸고요. 그게 내부적으로 다르다는 근거는 되지 않는다고 말씀도 이미 수차례 드렸습니다. 생긴 모양이 그렇게 보일 뿐 new Object 로 객체 생성하고 프로퍼티 붙이는 것과 다를 게 없다고도 말씀드렸고요. 던져주신 문서만 보고 이해하려 해도 대체 무슨 의도로 주신건지 이해가 안됩니다. 제가 부족하다면 정확하게 찍어주시고 예제도 부탁합니다. 정확히 어디를 보면 되나요? 영문 해석을 보면 object 가 evaluate 될 때마다 literal 안에 있는 문장이 해석된다 라고 하는데요, evaluate 된다는 것은 선언될 때를 말하는 걸로 보이는군요. 그건 당연한거라고 보고요. 함수안에서 사용된 initializer 는 함수가 호출될 때마다 선언된다고 하는데, 함수안에서 사용되었으면 당연한겁니다. 또한, 그 챕터의 다른 예제에서는 function car(){} 와 같은 식으로 흔히 말하는 OOP 적인 사용을 설명하고 있고요. 챕터 자체에서 사용된 Objects라는 단어가 우리가 논하고 있는 코어 Object가 아닌 각각의 객체들을 얘기하고 있습니다. new Object 와의 차이점이 아닌 function car() 를 정의하고 new Car() 를 사용하는 것과의 차이점을 설명하는 겁니다. 저 문장을 그냥 던져주신게 아닐텐데, 어떤 걸 보라고 주신건가요? new Object 와 {}간에는 어떤 차이가 있는 건가요? 가능하다면 예제도 하나 주시고요. 두번째에서, 에러는.. 제가 예제를 들 때 괄호로 감싸는 이유입니다. {}를 문법적으로 블럭의 시작으로 보기때문에 에러를 발생시키거든요(문서에도 그렇게 나왔죠). 이것은 {}가 객체를 생성하는 용도의 Object initializer 말고도 다른 용도(with, for, function 등을 정의할 때)로도 사용되기 때문에 인터프리터가 혼동을 일으키는 것에 불과합니다. 그래서, 제가 예제로 드릴 때 마다 항상 ({}) 과 같이 괄호로 감싸서 드렸잖습니까. 문법과 사용법이 다른게 어째서 내부적으로 다르다는 증거가 되는지를 묻는겁니다. ""과 new String 은 제가 찾은 것이긴 하지만 아주 쉽게 수긍했습니다. eval의 결과가 달랐으니, 두가지가 서로 다르다는 증거가 되는거죠. 하지만 여전히 {}과 new Object는 수긍이 안되는군요. P.S// 제가 무례하게 한 부분은 단어 선정이 과격했던 것 말고는 없다고 생각하는군요. 그리고 그 부분은 지나쳤다고 이미 사과했습니다. 불행하다고 부르셨던 것은 그냥 넘어가드리겠습니다.

숨어지내리   07-03-25 19:59   아휴...ㅡㅡ; 소모전에서 제가 졌습니다. 네 .. {} 과  new Object() 는 같습니다. ps. 덧글들의 표현들(불행, 쇼펜하우어)은 사과드리며, 이만 종료하면 좋겠습니다.     더이상의 답글을 달지 않도록 하겠습니다.     답글을 달지 않는다하여 욕을 하셔도 좋습니다. 이젠 힘듭니다..ㅠㅠ 아휴...ㅡㅡ; 소모전에서 제가 졌습니다. 네 .. {} 과 new Object() 는 같습니다. ps. 덧글들의 표현들(불행, 쇼펜하우어)은 사과드리며, 이만 종료하면 좋겠습니다. 더이상의 답글을 달지 않도록 하겠습니다. 답글을 달지 않는다하여 욕을 하셔도 좋습니다. 이젠 힘듭니다..ㅠㅠ

낭망백수   07-03-25 23:57   그래도 많이 배워갑니다. 두분다 감정은 상하지 마시고, 수고하셨습니다. 공부 많이 해야겠다는 생각이 드네요. 현업으로 복귀하는데 시간이 더 많이 걸릴 것 같습니다. ㅎㅎ 꾸벅~! 그래도 많이 배워갑니다. 두분다 감정은 상하지 마시고, 수고하셨습니다. 공부 많이 해야겠다는 생각이 드네요. 현업으로 복귀하는데 시간이 더 많이 걸릴 것 같습니다. ㅎㅎ 꾸벅~!

무소레즈   07-03-26 17:00   {} 는 상수개념으로 property 를 정의한 독립적인 하나의 개체이고, new Object 는 new 를 사용하여 새로운 instance 즉, 같은 자료구조를 가졌지만 instance 가 서로 다른 독립적인 개체를 생성합니다. {} 은 new Object 에의해 생성된 여러 instance 중에서 어느 한 개체와 (같은 자료구조 && 같은 property 값)을 가질 수는 있지만, 분명히  instance 는 다릅니다. 제가 알고 있는 것은 이렇습니다. {} 는 상수개념으로 property 를 정의한 독립적인 하나의 개체이고, new Object 는 new 를 사용하여 새로운 instance 즉, 같은 자료구조를 가졌지만 instance 가 서로 다른 독립적인 개체를 생성합니다. {} 은 new Object 에의해 생성된 여러 instance 중에서 어느 한 개체와 (같은 자료구조 && 같은 property 값)을 가질 수는 있지만, 분명히 instance 는 다릅니다. 제가 알고 있는 것은 이렇습니다.

행복한고니   07-03-26 18:13   저도 다시 시작하긴 싫은데, 정말로 그 "알고 계시는 것"에 대한 근거를 원합니다. 제가 바라는 건 단지 그것뿐입니다. 두 가지가 서로 다른 것이라면 다르다는 근거를 알고 싶을 뿐입니다. 또한, instance 가 다르다는 말이 어떻게 다르다는 말인지 표현이 애매합니다. 두 instance 간에 서로 identity가 다르다는 것인지 아니면 등가(equality)가 아니라는 것인지요. 참고로, ECMA 스펙에서는 new Object 를 생성한 것과 같은 결과를 리턴한다고 되어있습니다. 그에 관해서는 제가 아직도 이해하지 못한 숨어지내리님의 근거와 저 나름대로 들어놓았던 몇몇 근거가 있으니 읽어보시면 될 것 같습니다. 혹시 다른 근거가 있으시다면 다시 얘기를 나눌 의향도 있습니다. 저도 다시 시작하긴 싫은데, 정말로 그 "알고 계시는 것"에 대한 근거를 원합니다. 제가 바라는 건 단지 그것뿐입니다. 두 가지가 서로 다른 것이라면 다르다는 근거를 알고 싶을 뿐입니다. 또한, instance 가 다르다는 말이 어떻게 다르다는 말인지 표현이 애매합니다. 두 instance 간에 서로 identity가 다르다는 것인지 아니면 등가(equality)가 아니라는 것인지요. 참고로, ECMA 스펙에서는 new Object 를 생성한 것과 같은 결과를 리턴한다고 되어있습니다. 그에 관해서는 제가 아직도 이해하지 못한 숨어지내리님의 근거와 저 나름대로 들어놓았던 몇몇 근거가 있으니 읽어보시면 될 것 같습니다. 혹시 다른 근거가 있으시다면 다시 얘기를 나눌 의향도 있습니다.

무소레즈   07-03-26 21:50   function price ( a, b ) {   this.kr=a;   this.us=b; } meat1=new price(500,100); meat2=new price(700,100); 이와 같이 정의 되어 있을때, 객체타입 price 는 Function 타입의 instance  이고, 객체변수 meat1 과 meat2 는 price 타입의 instance 이며 또한 Object 타입의 instance 입니다. Object 타입인 meat1 과 meat2 의 instance 는 갈을지라도 서로간의 identity 나 equality 는 다릅니다. 각자 독립적인 개체이기때문입니다. copy_m1=meat1; alert(meat1 === meat2 );    // false alert(meat1 == meat2 );    // false alert(meat1 == copy_m1 ); // true a=new Object; b=new Object copy_a=a; alert (a===b);  // false alert (a==b);    // false alert (copy_a==a);  // true {} 와 new Object 는  내부적으로 임의의 비어있는 객체를 생성하여  instance 만을 반환(return) 하고, 생성자로써 사용된 그 임의의 객체는 소멸된다고 판단됩니다. Object() 함수내부에서 사용후 소멸되어 실제 생성자가 어떤 객체인지 알수가 없는 것이지요. meat1 과  meat2 는 모두 같은 instance 를 갖지만 {} 와 new Object() 에의해 생성된 instance 는 서로 다른 instance 를 갖게 된다고 봅니다. function price ( a, b ) { this.kr=a; this.us=b; } meat1=new price(500,100); meat2=new price(700,100); 이와 같이 정의 되어 있을때, 객체타입 price 는 Function 타입의 instance 이고, 객체변수 meat1 과 meat2 는 price 타입의 instance 이며 또한 Object 타입의 instance 입니다. Object 타입인 meat1 과 meat2 의 instance 는 갈을지라도 서로간의 identity 나 equality 는 다릅니다. 각자 독립적인 개체이기때문입니다. copy_m1=meat1; alert(meat1 === meat2 ); // false alert(meat1 == meat2 ); // false alert(meat1 == copy_m1 ); // true a=new Object; b=new Object copy_a=a; alert (a===b); // false alert (a==b); // false alert (copy_a==a); // true {} 와 new Object 는 내부적으로 임의의 비어있는 객체를 생성하여 instance 만을 반환(return) 하고, 생성자로써 사용된 그 임의의 객체는 소멸된다고 판단됩니다. Object() 함수내부에서 사용후 소멸되어 실제 생성자가 어떤 객체인지 알수가 없는 것이지요. meat1 과 meat2 는 모두 같은 instance 를 갖지만 {} 와 new Object() 에의해 생성된 instance 는 서로 다른 instance 를 갖게 된다고 봅니다.

행복한고니   07-03-26 22:41   1. 자바스크립트에서는 생성자 함수가 객체타입의 역할도 합니다. 2. price는 Function의 인스턴스이자 meat1, meat2의 타입입니다. 3. Object 역시 Function의 인스턴스입니다. 따라서 객체타입으로서의 역할을 충분히 한다고 생각합니다. 4. 어떤 객체의 생성자는 constructor 프로퍼티를 통해 알 수 있습니다. 생성자를 체크해보면 meat1 과 meat2는 price라고 나오고, {}과 new Object는 Object 라고 나옵니다. 따라서 내부적으로 임의의 빈 객체를 생성한다는 말이나, 생성자가 소멸된다는 말은 설득력을 잃습니다. 분명 생성자는 여전히 존재합니다. 추가로, var obj1 = new Object; var obj2 = {}; alert(obj1.constructor === obj2.constructor); 의 결과는 true입니다. 두 객체의 생성자는 완전히 똑같은 객체이며 alert(obj1.constructor === Object); 에서 보다시피 그것은 Object 입니다. 1. 자바스크립트에서는 생성자 함수가 객체타입의 역할도 합니다. 2. price는 Function의 인스턴스이자 meat1, meat2의 타입입니다. 3. Object 역시 Function의 인스턴스입니다. 따라서 객체타입으로서의 역할을 충분히 한다고 생각합니다. 4. 어떤 객체의 생성자는 constructor 프로퍼티를 통해 알 수 있습니다. 생성자를 체크해보면 meat1 과 meat2는 price라고 나오고, {}과 new Object는 Object 라고 나옵니다. 따라서 내부적으로 임의의 빈 객체를 생성한다는 말이나, 생성자가 소멸된다는 말은 설득력을 잃습니다. 분명 생성자는 여전히 존재합니다. 추가로, var obj1 = new Object; var obj2 = {}; alert(obj1.constructor === obj2.constructor); 의 결과는 true입니다. 두 객체의 생성자는 완전히 똑같은 객체이며 alert(obj1.constructor === Object); 에서 보다시피 그것은 Object 입니다.

숨어지내리   07-03-27 00:53   ㅡㅡ;; 계속 논쟁이 이어지고 있군요.. 왠만하면 행복한 고니님과 논쟁을 피하고 싶으나, 논쟁이 시작되었을떄부터 아니라고 생각한 부분이 진실이 되는걸 볼수 없어, 답글을 남깁니다. ㅠㅠ "Object 역시 Function의 인스턴스입니다." 이부분은 계속 말씀드렸듯이 core Object 즉 Object 가 최상위입니다.  http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Object 의 종합된 내용을 보면, Core Object Object is the primitive JavaScript object type. All JavaScript objects are descended from Object. That is, all JavaScript objects have the methods defined for Object. 모든 객체의 최상위는 core Object 라고 제가 계속적으로 말씀드린 상황입니다. Function 이라고 보여질뿐 모든 객체는  core Object 즉 Object 를 통해서 생성된다고 되어 있습니다. 즉 최상위의 객체는 Object 입니다. ㅡㅡ; 그리고 Object 의 constructor 는 new Object() 입니다. 또한 new Object() 는 Object 의 constructor 입니다. ㅡㅡ; Created by The Object constructor: new Object() 처음부터 제가 주장한 결과는 같지만, new Object() 와 {} 가 다르다는게, http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Using_Object_Initializers 의 If an object is created with an object initializer in a top-level script, JavaScript interprets the object each time it evaluates an expression containing the object literal. In addition, an initializer used in a function is created each time the function is called. 를 해석해서 생각해 보시라고 한게 그런것입니다. ㅡㅡ; core Object 의 constructor 는 new Object() 이고, {} 는 new Object() 처럼 동작 되어지는것이고, javascript 1.1 이하에서는 literal은 동작되지 않는다라고 되어 있습니다. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Using_Object_Initializers JavaScript 1.1 and earlier. You cannot use object initializers. You can create objects only using their constructor functions or using a function supplied by some other object for that purpose. See Using a Constructor Function. 1.1 이후 편의성에 의해서 생성된 문자(literal)이고, 그게 new Object() 처럼하는것이고요, In addition to creating objects using a constructor function, you can create objects using an object initializer. Using object initializers is sometimes referred to as creating objects with literal notation. "Object initializer" is consistent with the terminology used by C++. 위의 내용이 뒷바침해 주고 있는것이지요. 고니님이 주장하는 new Object() 와 {} 은 동일하게 객체를 생성할때 쓰이는게 맞으나, 엄밀하게는 쓰이는 용도와 차이가 있어 똑같다고 말하는건 잘못된거 같다고 한게, 제가 처음부터 말씀드린 내용입니다. ps. 이것에 대해 증명해보라 하지 마십시요. ^^; 기분나빠하시지도 말고요.     정말, 그냥 여기서 멈추었으면 좋겠습니다. ㅠㅠ;     전 단지 아닌 부분이 진실이 되어질까 하는 마음에 답글을 남깁니다.     숨어 지낼겁니다.ㅠㅠ ps2. http://zeldign.com/tt/38 ㅡㅡ;; 계속 논쟁이 이어지고 있군요.. 왠만하면 행복한 고니님과 논쟁을 피하고 싶으나, 논쟁이 시작되었을떄부터 아니라고 생각한 부분이 진실이 되는걸 볼수 없어, 답글을 남깁니다. ㅠㅠ "Object 역시 Function의 인스턴스입니다." 이부분은 계속 말씀드렸듯이 core Object 즉 Object 가 최상위입니다. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Object 의 종합된 내용을 보면, Core Object Object is the primitive JavaScript object type. All JavaScript objects are descended from Object. That is, all JavaScript objects have the methods defined for Object. 모든 객체의 최상위는 core Object 라고 제가 계속적으로 말씀드린 상황입니다. Function 이라고 보여질뿐 모든 객체는 core Object 즉 Object 를 통해서 생성된다고 되어 있습니다. 즉 최상위의 객체는 Object 입니다. ㅡㅡ; 그리고 Object 의 constructor 는 new Object() 입니다. 또한 new Object() 는 Object 의 constructor 입니다. ㅡㅡ; Created by The Object constructor: new Object() 처음부터 제가 주장한 결과는 같지만, new Object() 와 {} 가 다르다는게, http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Using_Object_Initializers 의 If an object is created with an object initializer in a top-level script, JavaScript interprets the object each time it evaluates an expression containing the object literal. In addition, an initializer used in a function is created each time the function is called. 를 해석해서 생각해 보시라고 한게 그런것입니다. ㅡㅡ; core Object 의 constructor 는 new Object() 이고, {} 는 new Object() 처럼 동작 되어지는것이고, javascript 1.1 이하에서는 literal은 동작되지 않는다라고 되어 있습니다. http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Using_Object_Initializers JavaScript 1.1 and earlier. You cannot use object initializers. You can create objects only using their constructor functions or using a function supplied by some other object for that purpose. See Using a Constructor Function. 1.1 이후 편의성에 의해서 생성된 문자(literal)이고, 그게 new Object() 처럼하는것이고요, In addition to creating objects using a constructor function, you can create objects using an object initializer. Using object initializers is sometimes referred to as creating objects with literal notation. "Object initializer" is consistent with the terminology used by C++. 위의 내용이 뒷바침해 주고 있는것이지요. 고니님이 주장하는 new Object() 와 {} 은 동일하게 객체를 생성할때 쓰이는게 맞으나, 엄밀하게는 쓰이는 용도와 차이가 있어 똑같다고 말하는건 잘못된거 같다고 한게, 제가 처음부터 말씀드린 내용입니다. ps. 이것에 대해 증명해보라 하지 마십시요. ^^; 기분나빠하시지도 말고요. 정말, 그냥 여기서 멈추었으면 좋겠습니다. ㅠㅠ; 전 단지 아닌 부분이 진실이 되어질까 하는 마음에 답글을 남깁니다. 숨어 지낼겁니다.ㅠㅠ ps2. http://zeldign.com/tt/38

행복한고니   07-03-27 02:33   다시 나올지 몰랐네요. 혹시나 했는데, 역시나... Function 이 Object 을 상속한 것은 맞지만, Object 역시 Function의 인스턴스입니다. 자바스크립트 언어의 특징이라 볼 수 있는 prototype chain 에 의해서 말이죠. 님과는 달리 저는 증명이 뒤따르지 않으면 믿지 않습니다. 그래서 또 근거를 드리죠. alert(Object.aa); Function.prototype.aa = 'bb'; alert(Object.aa); 실행해보시고 그럼 이게 어떻게 다르게 해석될 수 있는지 다시 말씀해주세요. "내부적으로 다르다"는 근거도 없는 그런 막연한 말씀은 빼고요. 그 전부터 느끼고 있던 것인데요, 왜 문서에 없는 부분을 자꾸 첨가하시는 건지 모르겠습니다. 자바스크립트의 모든 객체들이 Object 를 상속하는 것은 맞습니다. 당연한 사실이죠. 하지만, 그게 Object가 Function의 인스턴스가 아니라는 말은 안된다는 말입니다. 거기 어디에 그런 문장이 있는지 짚어주세요. 만약, 문서에 그리 나와있었으면 제가 인정해드리겠습니다만, 문서에 없는 내용을 자꾸 첨언하고 계시잖습니까? 자의적인 해석 말고 있는 그대로 보세요. 제가 말한 것이 설령 그른 내용일지라도 저는 코드상에서 비춰지는 사실 그 자체만을 말하고 있고요, 님께서는 문서상에 없는 말을 첨언하고서 저더러 믿으라고 하시는군요. core Object의 constructor 가 new Object 라는 말은 잘못하신거겠죠? constructor 라면 자바스크립트가 아닌 (최소한 제가 아는)다른 어떤 언어에서라도 생성자는 메소드/함수가 되어야 할텐데 Object 도 아닌 new Object 가 constructor 가 된다는 말씀인가요? 자바스크립트는 함수가 아닌 객체 자체를 생성자로 사용할 수 있다니 무척 놀라워하고 있습니다. ________________________________________________ Create by 부분에서 제대로 웃었습니다. ㅎㅎ http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Array http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Number Array의 constructor 는 new Array 군요. Number 의 constructor 역시 new Number 구요? ㅎㅎㅎ ________________________________________________ 잠깐 재밌었으니 다시, 'In addition to'... 이 부분은 사용자가 명시적으로 constructor function 을 이용해서 생성하는 방법 외에 Object initializer 라는 방법을 사용할 수 있다라는 내용입니다. 물론, 사용과 동시에 객체에 프로퍼티를 지정하는 등의 초기화가 가능하니까 initializer 라 부르는 것이고요. 이 부분에 대해서도 ECMA에도 나와있다고 제가 말했으며, "방법만 다를 뿐" 같은 결과라고도 했습니다. 이게 왜 님의 주장을 뒷받침해주는 것인지 말씀해주세요. new Function 으로 함수를 만들 수도 있고 function 선언으로 만들 수도 있습니다. 중요한 것은 적재적소에 쓰는 게 맞습니다. 하지만, 용도가 다르다고 코드의 생김새가 다르다고 "객체가 다르다"고 주장하는 것은 논리적 비약이죠. 인스턴스 객체를 초기화하면서 생성할 때 {}가 더 유용한 것은 사실이나 "더 유용하다"라는 사실이 "서로 다르다"를 증명하지는 못한다는 말입니다. 꼼수건 정석이건 제대로 알고 쓰셔야죠. ________________________________________________ 블로그에서 영문해석을 조금 잘못하신 것 같은데, 함수처럼 쓰인다는 말은 그 문장에 없고요, {}가 "함수에서 사용되었을 때"와 "함수가 호출될 때" 밖에 없습니다. 어디에 함수처럼 쓰인다고 써있나요? an initializer used in a function is created each time the function is called. >> 함수에서 사용된 initializer는 해당 함수가 호출될 때마다 생성된다. 그래서 당연하다고 했는데요? 당연하다고 했을 때는 듣지도 않고 안한다고 하시더니 이제 와서 또 딴소리를... function aa() {     var bb = {}; } function aa() {     var bb = new Object; } 어떻게 하면 함수가 호출될 때마다 생성되지 않을 수 있을까요? 그 챕터가 전체적으로 의미하는 바를 잘못 짚으셨다고 위에서도 말했는데, 그 챕터는 new Object 와의 차이점이 아니라,사용자가 객체 타입을 정의했을 때와 비교하는 겁니다. 지금 논리적인 착각을 하고 계시는 듯 해서 정리해드리면요. "용도"와 "모양"은 그 사물의 "본질"을 결정짓는 절대적인 요소가 아닙니다. 오히려 "성질"이 본질을 결정짓는 중요한 요소인거죠. P.S1// 인정하는 모습이 꽤 찝찝하긴 했어도 그냥 그러려니 했는데, 역시 이러시는군요. 그럴바엔 그런 성의없는 인정한다는 말도 안하는 편이 훨씬 좋았을텐데요. 인정했다고 하지 말던지, 기껏 블로그에서 다른 소리 하는게 님의 스타일이시군요. 잘 알겠습니다. P.S2// 증명도 못하는 고집은 이제 그만 꺾으십시오. 차라리 코드로 나름의 논리가 있는 무소레즈님과 얘기하는 편이 훨씬 더 유익합니다. 초보자들 이제 그만 현혹시키세요. P.S3// 영문해석을 그리 잘하시지는 못하시는 것 같습니다. ^^ P.S4// 아... 이번엔 재밌었습니다. 특히 Create by 가요. ;) 다시 나올지 몰랐네요. 혹시나 했는데, 역시나... Function 이 Object 을 상속한 것은 맞지만, Object 역시 Function의 인스턴스입니다. 자바스크립트 언어의 특징이라 볼 수 있는 prototype chain 에 의해서 말이죠. 님과는 달리 저는 증명이 뒤따르지 않으면 믿지 않습니다. 그래서 또 근거를 드리죠. alert(Object.aa); Function.prototype.aa = 'bb'; alert(Object.aa); 실행해보시고 그럼 이게 어떻게 다르게 해석될 수 있는지 다시 말씀해주세요. "내부적으로 다르다"는 근거도 없는 그런 막연한 말씀은 빼고요. 그 전부터 느끼고 있던 것인데요, 왜 문서에 없는 부분을 자꾸 첨가하시는 건지 모르겠습니다. 자바스크립트의 모든 객체들이 Object 를 상속하는 것은 맞습니다. 당연한 사실이죠. 하지만, 그게 Object가 Function의 인스턴스가 아니라는 말은 안된다는 말입니다. 거기 어디에 그런 문장이 있는지 짚어주세요. 만약, 문서에 그리 나와있었으면 제가 인정해드리겠습니다만, 문서에 없는 내용을 자꾸 첨언하고 계시잖습니까? 자의적인 해석 말고 있는 그대로 보세요. 제가 말한 것이 설령 그른 내용일지라도 저는 코드상에서 비춰지는 사실 그 자체만을 말하고 있고요, 님께서는 문서상에 없는 말을 첨언하고서 저더러 믿으라고 하시는군요. core Object의 constructor 가 new Object 라는 말은 잘못하신거겠죠? constructor 라면 자바스크립트가 아닌 (최소한 제가 아는)다른 어떤 언어에서라도 생성자는 메소드/함수가 되어야 할텐데 Object 도 아닌 new Object 가 constructor 가 된다는 말씀인가요? 자바스크립트는 함수가 아닌 객체 자체를 생성자로 사용할 수 있다니 무척 놀라워하고 있습니다. ________________________________________________ Create by 부분에서 제대로 웃었습니다. ㅎㅎ http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Array http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Number Array의 constructor 는 new Array 군요. Number 의 constructor 역시 new Number 구요? ㅎㅎㅎ ________________________________________________ 잠깐 재밌었으니 다시, 'In addition to'... 이 부분은 사용자가 명시적으로 constructor function 을 이용해서 생성하는 방법 외에 Object initializer 라는 방법을 사용할 수 있다라는 내용입니다. 물론, 사용과 동시에 객체에 프로퍼티를 지정하는 등의 초기화가 가능하니까 initializer 라 부르는 것이고요. 이 부분에 대해서도 ECMA에도 나와있다고 제가 말했으며, "방법만 다를 뿐" 같은 결과라고도 했습니다. 이게 왜 님의 주장을 뒷받침해주는 것인지 말씀해주세요. new Function 으로 함수를 만들 수도 있고 function 선언으로 만들 수도 있습니다. 중요한 것은 적재적소에 쓰는 게 맞습니다. 하지만, 용도가 다르다고 코드의 생김새가 다르다고 "객체가 다르다"고 주장하는 것은 논리적 비약이죠. 인스턴스 객체를 초기화하면서 생성할 때 {}가 더 유용한 것은 사실이나 "더 유용하다"라는 사실이 "서로 다르다"를 증명하지는 못한다는 말입니다. 꼼수건 정석이건 제대로 알고 쓰셔야죠. ________________________________________________ 블로그에서 영문해석을 조금 잘못하신 것 같은데, 함수처럼 쓰인다는 말은 그 문장에 없고요, {}가 "함수에서 사용되었을 때"와 "함수가 호출될 때" 밖에 없습니다. 어디에 함수처럼 쓰인다고 써있나요? an initializer used in a function is created each time the function is called. >> 함수에서 사용된 initializer는 해당 함수가 호출될 때마다 생성된다. 그래서 당연하다고 했는데요? 당연하다고 했을 때는 듣지도 않고 안한다고 하시더니 이제 와서 또 딴소리를... function aa() { var bb = {}; } function aa() { var bb = new Object; } 어떻게 하면 함수가 호출될 때마다 생성되지 않을 수 있을까요? 그 챕터가 전체적으로 의미하는 바를 잘못 짚으셨다고 위에서도 말했는데, 그 챕터는 new Object 와의 차이점이 아니라,사용자가 객체 타입을 정의했을 때와 비교하는 겁니다. 지금 논리적인 착각을 하고 계시는 듯 해서 정리해드리면요. "용도"와 "모양"은 그 사물의 "본질"을 결정짓는 절대적인 요소가 아닙니다. 오히려 "성질"이 본질을 결정짓는 중요한 요소인거죠. P.S1// 인정하는 모습이 꽤 찝찝하긴 했어도 그냥 그러려니 했는데, 역시 이러시는군요. 그럴바엔 그런 성의없는 인정한다는 말도 안하는 편이 훨씬 좋았을텐데요. 인정했다고 하지 말던지, 기껏 블로그에서 다른 소리 하는게 님의 스타일이시군요. 잘 알겠습니다. P.S2// 증명도 못하는 고집은 이제 그만 꺾으십시오. 차라리 코드로 나름의 논리가 있는 무소레즈님과 얘기하는 편이 훨씬 더 유익합니다. 초보자들 이제 그만 현혹시키세요. P.S3// 영문해석을 그리 잘하시지는 못하시는 것 같습니다. ^^ P.S4// 아... 이번엔 재밌었습니다. 특히 Create by 가요. ;)

숨어지내리   07-03-27 03:07   ㅎㅎㅎ creaed by 부분은 잠시 생각하고 잠자리에 누웠다가 바로 일어나서 확인했네요..^^;; 성급한 해석이었던듯 ..^^ 인정.!! ㅎㅎㅎ creaed by 부분은 잠시 생각하고 잠자리에 누웠다가 바로 일어나서 확인했네요..^^;; 성급한 해석이었던듯 ..^^ 인정.!!

숨어지내리   07-03-27 05:41   prototype chain 대한 명제이니, 아래의 예제는 참일수밖에 없습니다. ^^; alert(Object.aa); Function.prototype.aa = 'bb'; alert(Object.aa); 제가 고니님을 반박했던 Object.prototype.someFunc = function() { alert('hello~') }; ({}).someFunc(); (new Object).someFunc(); (new Array).someFunc(); 위와 같은 내용과 같은 것이니깐요. ^^; 허나 제가 보는 입장은 고니님이 ---------------------------------------------------------------------------------------------------  "용도"와 "모양"은 그 사물의 "본질"을 결정짓는 절대적인 요소가 아닙니다. --------------------------------------------------------------------------------------------------- 와 같이 말했듯이 new Object() 와 {} 은 용도는 같다는 것입니다. 따라서 본질이 같다고 까지 할수 없다라는 것이죠. 본질을 결정짓는것은 성질일수도 있지만, 특징일수도 있는것입니다. 이미 앞에서도 언급해 드린대로 setter 와 getter 의 생성에 대한 특징 부분에서 ----------------------------------------------------------------------------------- " When defining getters and setters using object initializers all you need to do is to prefix a getter method with get and a setter method with set 허나, setter 와 getter 를 preifx 시키기 위해 object initializers 를 사용한다 되어 있습니다. 그리고 new Object() 선언할때 , setter 와 getter 는 만들수 없습니다. ㅡㅡ; added later to any object at any time using 이죠.. ㅡㅡ;  " ----------------------------------------------------------------------------------- 위와 같은 성질과 함께 특징을 가지고 있는게 {} 이기 때문에 똑같다는 표현은 아니라는 것입니다. 행복한 고니님이 말한  new Object() 와 {} 의 본질은 무엇인가요? 막연히 똑같다? 는 입니까??? 객체의 constructor 와 prototype 이 같기때문에 본질도 같다? 저야말로 수긍하기 어렵습니다. ps. 새벽 늦게 글을 보다, 고니님이 Function 이 최상위 인듯 얘기하는것 같아,     글을 남겼는데... 또 논쟁으로 빠져버렸네요.. ㅡㅡ;     또 자세히 보니 " Object 역시 Function의 인스턴스입니다 " 이군요.     이제부턴 새벽에는 phpschool 에는 들어가지 말아야 할것 같네요..ㅡㅡ;     제가 반박한 prototype chain 에 제가 걸려 넘어졌네요.. ^^; prototype chain 대한 명제이니, 아래의 예제는 참일수밖에 없습니다. ^^; alert(Object.aa); Function.prototype.aa = 'bb'; alert(Object.aa); 제가 고니님을 반박했던 Object.prototype.someFunc = function() { alert('hello~') }; ({}).someFunc(); (new Object).someFunc(); (new Array).someFunc(); 위와 같은 내용과 같은 것이니깐요. ^^; 허나 제가 보는 입장은 고니님이 --------------------------------------------------------------------------------------------------- "용도"와 "모양"은 그 사물의 "본질"을 결정짓는 절대적인 요소가 아닙니다. --------------------------------------------------------------------------------------------------- 와 같이 말했듯이 new Object() 와 {} 은 용도는 같다는 것입니다. 따라서 본질이 같다고 까지 할수 없다라는 것이죠. 본질을 결정짓는것은 성질일수도 있지만, 특징일수도 있는것입니다. 이미 앞에서도 언급해 드린대로 setter 와 getter 의 생성에 대한 특징 부분에서 ----------------------------------------------------------------------------------- " When defining getters and setters using object initializers all you need to do is to prefix a getter method with get and a setter method with set 허나, setter 와 getter 를 preifx 시키기 위해 object initializers 를 사용한다 되어 있습니다. 그리고 new Object() 선언할때 , setter 와 getter 는 만들수 없습니다. ㅡㅡ; added later to any object at any time using 이죠.. ㅡㅡ; " ----------------------------------------------------------------------------------- 위와 같은 성질과 함께 특징을 가지고 있는게 {} 이기 때문에 똑같다는 표현은 아니라는 것입니다. 행복한 고니님이 말한 new Object() 와 {} 의 본질은 무엇인가요? 막연히 똑같다? 는 입니까??? 객체의 constructor 와 prototype 이 같기때문에 본질도 같다? 저야말로 수긍하기 어렵습니다. ps. 새벽 늦게 글을 보다, 고니님이 Function 이 최상위 인듯 얘기하는것 같아, 글을 남겼는데... 또 논쟁으로 빠져버렸네요.. ㅡㅡ; 또 자세히 보니 " Object 역시 Function의 인스턴스입니다 " 이군요. 이제부턴 새벽에는 phpschool 에는 들어가지 말아야 할것 같네요..ㅡㅡ; 제가 반박한 prototype chain 에 제가 걸려 넘어졌네요.. ^^;

ε♡з   07-03-27 06:23   기술적인 부분을 이해는 못하지만 오랫만에 보는 흥미진진한 논쟁이네효. 쇼펜하우어까지 나오구요 >_<;; 이해가 됬으면 더 재밌을텐데 아쉽습니다. 쇼펜하우어 책을 보셨으면 아실테지만 논쟁에서 객관적인 승리는 불가능하다고 써있습니다. 다만 자신에게 유리하게 몰아가는 법이 있습니다. 내 주장은 좁히며 상대방 주장은 확대해석하는 법입니다. ㄳ (기술적인 부분을 이해했으면 누가 확대해석 하는지 알 수 있을텐데 >_<) 이부분을 달리 생각해보면.. 서로 심플하게 자신의 주장을 내세운다면 어긋났던 부분은 분명 잡힌다는 겁니다.. 아무쪼록 끝을 보시는게 인류발전에 도움이 될듯.. ㄳㄳ ps) 제 리플은 무시하고 고고싱~ ㄳ 기술적인 부분을 이해는 못하지만 오랫만에 보는 흥미진진한 논쟁이네효. 쇼펜하우어까지 나오구요 >_<;; 이해가 됬으면 더 재밌을텐데 아쉽습니다. 쇼펜하우어 책을 보셨으면 아실테지만 논쟁에서 객관적인 승리는 불가능하다고 써있습니다. 다만 자신에게 유리하게 몰아가는 법이 있습니다. 내 주장은 좁히며 상대방 주장은 확대해석하는 법입니다. ㄳ (기술적인 부분을 이해했으면 누가 확대해석 하는지 알 수 있을텐데 >_<) 이부분을 달리 생각해보면.. 서로 심플하게 자신의 주장을 내세운다면 어긋났던 부분은 분명 잡힌다는 겁니다.. 아무쪼록 끝을 보시는게 인류발전에 도움이 될듯.. ㄳㄳ ps) 제 리플은 무시하고 고고싱~ ㄳ

숨어지내리   07-03-27 06:35   잠 다깨고, 날 샜네요..ㅡㅡ; 덴장. 1. new Object() 와 {} 의 결과는 같다. 2. 허나 차이가 있다. 3. 따라서 똑같다고 말하는것은 어불성설이다. '고니님이 말한 각각의 본질이 있다.' 잠 다깨고, 날 샜네요..ㅡㅡ; 덴장. 1. new Object() 와 {} 의 결과는 같다. 2. 허나 차이가 있다. 3. 따라서 똑같다고 말하는것은 어불성설이다. '고니님이 말한 각각의 본질이 있다.'

행복한고니   07-03-27 11:18   아... gettter 와 setter 를 prefix 한다는 말 말인데요, 정확하게는 get 으로 getter를 표시해주고, set 으로 setter를 명시해주기 위해서 사용한다는 말입니다. 단지 문법적이고 방법적인 특징일 뿐이라고도 말씀드렸던 것 같군요. 코드의 모양이 다르니까 달라보이겠지만, 본질은 같다는 거죠. 여태까지 방법적인 차이 말고 무엇을 증명하셨는지 모르겠군요. 했던 얘기 또 하고, 했던 얘기 또 하고... 방법의 차이는 어느 누가 봐도 존재하고(코드의 모양이 다르니까), 또 저 역시 처음부터 방법적인 차이는 있다고 말했었는데 말이죠. 왜 누구나 아는 보편적 사실을 가지고, 그게 갑자기 "본질의 차이"를 만들어내는 방법이 되는지 논리를 이해할 수가 없군요. 문법적인 편의성이 "본질"을 결정짓는 중요한 요소가 될 수 있었군요. ^^ 뭐... 그냥 그렇게 생각하고 계시라는 말 밖에는 할 말이 없네요. 이미 어떤 말을 해도 인정을 안들으실 것 같으니까요. 그나마 처음에는 new Object와 {}의 결과가 같은 것도 인정안하더니 그나마 조금 낫군요. 증명도 안되는 논리에 상대해주는 것도 이젠 그만하렵니다. 열심히 사세요 :) 아... gettter 와 setter 를 prefix 한다는 말 말인데요, 정확하게는 get 으로 getter를 표시해주고, set 으로 setter를 명시해주기 위해서 사용한다는 말입니다. 단지 문법적이고 방법적인 특징일 뿐이라고도 말씀드렸던 것 같군요. 코드의 모양이 다르니까 달라보이겠지만, 본질은 같다는 거죠. 여태까지 방법적인 차이 말고 무엇을 증명하셨는지 모르겠군요. 했던 얘기 또 하고, 했던 얘기 또 하고... 방법의 차이는 어느 누가 봐도 존재하고(코드의 모양이 다르니까), 또 저 역시 처음부터 방법적인 차이는 있다고 말했었는데 말이죠. 왜 누구나 아는 보편적 사실을 가지고, 그게 갑자기 "본질의 차이"를 만들어내는 방법이 되는지 논리를 이해할 수가 없군요. 문법적인 편의성이 "본질"을 결정짓는 중요한 요소가 될 수 있었군요. ^^ 뭐... 그냥 그렇게 생각하고 계시라는 말 밖에는 할 말이 없네요. 이미 어떤 말을 해도 인정을 안들으실 것 같으니까요. 그나마 처음에는 new Object와 {}의 결과가 같은 것도 인정안하더니 그나마 조금 낫군요. 증명도 안되는 논리에 상대해주는 것도 이젠 그만하렵니다. 열심히 사세요 :)

숨어지내리   07-03-27 13:41   prefix 를 잘 설명해 주시네요.. ^^; get 으로 getter 를 명시해 주는거랑 getter 를 prefix 해주는거랑 set 으로 setter 를 명시해주는거랑 setter 를 prefix 해 주는거랑 무슨 차이가 있는지 모르겠네요.. 목적은 getter 와 setter 를 명시해 주는것인데? ㅡㅡ; 혹시 영어해석이 틀린게 아닌지 잡아내려고? (그렇다면, 소심하시다.. ㅡㅡ) 본질은 prefix 인데요.. ㅡㅡ; 그럼 new Object() 는 선언될떄부터 명시해주나요.? 아 그래서 같은 거구나 라고 말할수 있는 근거를 말도 못하면서, 본질 얘기 하더니 참 재미있네요..^^ 제 대화의 시작과 핵심은 {} 과 new Object() 는 결과는 같을지라도, 서로 차이가 있다 라는 것입니다. code 로 들이밀면서 constructor 가 같은니 완전히 같다 라고 말하는것자제가 본질을 무시하고 결과가 같으니깐, 같다라고 말하는것과 무슨 차이가 있나요? 말하는것과 같이 생성자가 같으면 모두 같다면, alert(Array.constructor); alert(Object.constructor); alert(Function.constructor); alert(Number.constructor); alert(Array.constructor === Object.constructor); alert(Array.constructor === Object.constructor); alert(Array.constructor === Function.constructor); alert(Array.constructor === Number.constructor); alert(Function.prototype.constructor.constructor); alert(Array.prototype.constructor.constructor === Function.prototype.constructor.constructor); alert(Array.prototype.constructor.constructor === Number.prototype.constructor.constructor); alert(Array.prototype.constructor.constructor === Object.prototype.constructor.constructor); alert(Object.prototype.constructor.constructor === Object.prototype.constructor.constructor); alert(Array.prototype.constructor.constructor === Array.prototype.constructor.constructor); 아.. Array === Object === Function === Number  모두가 같네.. 캬~ 차이가 없네.. 결국은 모두 같은게야~~ 고니님의 이론 재미있었습니다. ㅋㅋ 저게 다르다는걸 입증해 보는것도 고니님의 숙제 같네요..^^ '문서에 다르다고 되어 있어요' 라고 하면, 고니님의 주장은 설득력을 완전히 상실하겠네요. constructor 가 같으면 다 같으니 말입니다. ㅋ 본질을 부정하시지 말아요~ 제발 .. ^^ 전 잘먹고 잘살고 있으니, 제 걱정 안하셔도 될거 같네요. ㅋ ps. 코드로 들이미는거 좋아하시나봐요? 자 저코드는 무얼의미하는지 ㅋ 제가 걸려 넘어졌던 prototype chain 인데..ㅋㅋ 고니님의 의견대로 모두가 같으니말입니다. ㅋ ps2. 제 의견의 뜻을 모를까봐 . var obj1 = new Object; var obj2 = {}; alert(obj1.constructor === obj2.constructor); new Object() 의 constructor 와 {} 의 constructor 는 같으니깐 . Object 이다. 그럼 Object 의 constructor 와 Function 의 constructor 가 같고 다 같으니깐, 모두가 다 같으면, 의미가 없다라는것이죠? ㅡㅡ; 그러니, 너무 깊게 들어가면 어차피 prototype chain 에 걸려 자빠지니, 그냥 {} 와 new Object() 는 용도는 같다. 하지만 본질은 다르니, {} 는 javscript 1.1 이후에 나온거고, setter 와 getter 를 prefix 해 주니 어느정도 그 목적과 본질이 있는건 아닌지 라고 생각해 보라는것입니다. ㅡㅡ; ps3. "왜 누구나 아는 보편적 사실을 가지고, 그게 갑자기 "본질의 차이"를 만들어내는 방법이 되는지 논리를 이해할 수가 없군요. 문법적인 편의성이 "본질"을 결정짓는 중요한 요소가 될 수 있었군요. ^^ " 편의성이라 판단하시다니, 대단합니다. ㅡㅡ; 특징을 편의성이라고 못박으시니... 그러니, 누구나 다 아는 보편적 사실을 가지고, 일관되게 주장해온 constructor 가 같다는 보편적사실을 가지고 여태 쭉 본질의 차이점에 대해 주장해온게 누군지 상상해 보시면 좋을것 같습니다. ^^ ps4. 자, 이로써 소정의 목적달성을 한 저는 이만 숨어지냅니다.       솔직히 영어해석 딸립니다. ㅋㅋ 주관적으로 해석하지 않으려고 노력하는데도..ㅋ       제가 질문한 코드가 저 부분이 다르다고 고니님이 입증하면,       다시 와서 글남겨버리겠지만,       아마도 짱구가 아니라면, 본질을 부정하지는 않을 겁니다. :)       보시는 분들 수고 많으셨습니다.. 아마도 답글은 달리지 않을것으로 판단됩니다. :)       http://zeldign.com/tt/38 prefix 를 잘 설명해 주시네요.. ^^; get 으로 getter 를 명시해 주는거랑 getter 를 prefix 해주는거랑 set 으로 setter 를 명시해주는거랑 setter 를 prefix 해 주는거랑 무슨 차이가 있는지 모르겠네요.. 목적은 getter 와 setter 를 명시해 주는것인데? ㅡㅡ; 혹시 영어해석이 틀린게 아닌지 잡아내려고? (그렇다면, 소심하시다.. ㅡㅡ) 본질은 prefix 인데요.. ㅡㅡ; 그럼 new Object() 는 선언될떄부터 명시해주나요.? 아 그래서 같은 거구나 라고 말할수 있는 근거를 말도 못하면서, 본질 얘기 하더니 참 재미있네요..^^ 제 대화의 시작과 핵심은 {} 과 new Object() 는 결과는 같을지라도, 서로 차이가 있다 라는 것입니다. code 로 들이밀면서 constructor 가 같은니 완전히 같다 라고 말하는것자제가 본질을 무시하고 결과가 같으니깐, 같다라고 말하는것과 무슨 차이가 있나요? 말하는것과 같이 생성자가 같으면 모두 같다면, alert(Array.constructor); alert(Object.constructor); alert(Function.constructor); alert(Number.constructor); alert(Array.constructor === Object.constructor); alert(Array.constructor === Object.constructor); alert(Array.constructor === Function.constructor); alert(Array.constructor === Number.constructor); alert(Function.prototype.constructor.constructor); alert(Array.prototype.constructor.constructor === Function.prototype.constructor.constructor); alert(Array.prototype.constructor.constructor === Number.prototype.constructor.constructor); alert(Array.prototype.constructor.constructor === Object.prototype.constructor.constructor); alert(Object.prototype.constructor.constructor === Object.prototype.constructor.constructor); alert(Array.prototype.constructor.constructor === Array.prototype.constructor.constructor); 아.. Array === Object === Function === Number 모두가 같네.. 캬~ 차이가 없네.. 결국은 모두 같은게야~~ 고니님의 이론 재미있었습니다. ㅋㅋ 저게 다르다는걸 입증해 보는것도 고니님의 숙제 같네요..^^ '문서에 다르다고 되어 있어요' 라고 하면, 고니님의 주장은 설득력을 완전히 상실하겠네요. constructor 가 같으면 다 같으니 말입니다. ㅋ 본질을 부정하시지 말아요~ 제발 .. ^^ 전 잘먹고 잘살고 있으니, 제 걱정 안하셔도 될거 같네요. ㅋ ps. 코드로 들이미는거 좋아하시나봐요? 자 저코드는 무얼의미하는지 ㅋ 제가 걸려 넘어졌던 prototype chain 인데..ㅋㅋ 고니님의 의견대로 모두가 같으니말입니다. ㅋ ps2. 제 의견의 뜻을 모를까봐 . var obj1 = new Object; var obj2 = {}; alert(obj1.constructor === obj2.constructor); new Object() 의 constructor 와 {} 의 constructor 는 같으니깐 . Object 이다. 그럼 Object 의 constructor 와 Function 의 constructor 가 같고 다 같으니깐, 모두가 다 같으면, 의미가 없다라는것이죠? ㅡㅡ; 그러니, 너무 깊게 들어가면 어차피 prototype chain 에 걸려 자빠지니, 그냥 {} 와 new Object() 는 용도는 같다. 하지만 본질은 다르니, {} 는 javscript 1.1 이후에 나온거고, setter 와 getter 를 prefix 해 주니 어느정도 그 목적과 본질이 있는건 아닌지 라고 생각해 보라는것입니다. ㅡㅡ; ps3. "왜 누구나 아는 보편적 사실을 가지고, 그게 갑자기 "본질의 차이"를 만들어내는 방법이 되는지 논리를 이해할 수가 없군요. 문법적인 편의성이 "본질"을 결정짓는 중요한 요소가 될 수 있었군요. ^^ " 편의성이라 판단하시다니, 대단합니다. ㅡㅡ; 특징을 편의성이라고 못박으시니... 그러니, 누구나 다 아는 보편적 사실을 가지고, 일관되게 주장해온 constructor 가 같다는 보편적사실을 가지고 여태 쭉 본질의 차이점에 대해 주장해온게 누군지 상상해 보시면 좋을것 같습니다. ^^ ps4. 자, 이로써 소정의 목적달성을 한 저는 이만 숨어지냅니다. 솔직히 영어해석 딸립니다. ㅋㅋ 주관적으로 해석하지 않으려고 노력하는데도..ㅋ 제가 질문한 코드가 저 부분이 다르다고 고니님이 입증하면, 다시 와서 글남겨버리겠지만, 아마도 짱구가 아니라면, 본질을 부정하지는 않을 겁니다. :) 보시는 분들 수고 많으셨습니다.. 아마도 답글은 달리지 않을것으로 판단됩니다. :) http://zeldign.com/tt/38

행복한고니   07-03-27 16:34   ㅎㅎㅎ 유머감각있으시네요. 지금 객체 타입으로서의 객체와 인스턴스로서의 객체를 혼동하고 계십니다. 으하하... 저라면 Function의 constructor가 Function으로 나올때부터 이상하다고 생각했을 텐데 그런 생각은 못하셨나봐요? 죄송하지만, 자바스크립트... 잘 모르시죠? 객체 타입이 Function의 인스턴스로 나타나는 것은 자바스크립트의 특징인 것입니다. 말하자면 class type1, class type2 를 지정하는 것과 같은 것이라는 말이죠. 그렇다고 type1과 type2 를 같은 클래스라고 하지는 않죠. 그게 바로 님께서 범한 오류입니다. 똑같이 class로 선언된다고 두개가 같은 클래스인가요? "클래스"라는 사실은 같겠죠. ㅋㅋ 객체 타입이 Function의 인스턴스로 나타나는 것은 자바스크립트의 특징, 그 중에서도 객체 타입선언의 특.수.성이라는 말입니다. 이러한 특수성을 가지고 마치 전체인양 호도하시다니 유머감각이 대단하시군요. ㅎㅎㅎ 제 말이 틀린 것이라면, 자료구조가 아닌 다른 인스턴스들을 한번 비교해보세요. ㅎㅎ 특수성이라는 말이 틀렸나요? 그러면 어떻게 Function의 생성자가 다시 Function이 될 수 있을지 한번 생각해보세요. 자료구조의 constructor를 비교해서 얘네가 다 Function이라고 말하는 것은 "얘네 모두 자료구조야"라는 말밖에 안된다는 겁니다. 아셨어요? ^^ 적어두세요. 특.수.성. constructor 한번 비교한 것은 그나마 봐줄 만 했습니다. constructor를 여러번 하면 당연히 최상위 객체가 나오겠죠. 그런데 상위객체를 비교해놓고서 "당신이 틀렸다"라고 하고 있으니, 상속의 개념... 잘 모르세요? 기껏 가져온다는 코드가 이런거라니... 참... 자, 이제... 생성자가 같고, 타입이 같고, 성질이 같은 두 객체가 어떻게 다르다고 볼 수 있는지 다시 말씀해보세요. 힘드셔서 그랬겠지만, 자료구조가 Function 객체라는 특수성을 가지고 호도할 생각은 마시고요. :) 요약 : 비교 자체가 틀려서 논할 가치도 없다. P.S1// 영어해석 딸리는 것은 알고있으니, 괘념치 마세요. P.S2// 방금은 쇼펜하우어 법칙 14번이네요. 역시 마스터하셨군요! _________________________________ 혹시 또 이해를 못하셨을까봐 님께서 하셨던 비유를 제가 설명해드리죠. var num1 = 1; var num2 = 2; alert(num1.constructor === num2.constructor); 이렇다고 num1과 num2의 "값"이 같은거냐고 묻고 있는겁니다. 두 객체의 indentity는 분명 다르고 값도 다르지만, "Number"의 특징을 지니고 있는 완전히 똑같은 "본질"(=숫자)의 객체임은 같은겁니다. 님께서 했던 그 코드는 말이죠. Array가 자료구조 맞아? Object가 자료구조 맞아? 이것만 비교한 것말고는 아무런 의미도 가지지 못한다는 거죠. Array === Object는 아니죠. identity도 다르고 값도 다르니까요. 하지만 "자료구조"임에는 확실히 맞습니다. 그게 Array와 Object의 "본질"이죠. 단지 "자료구조"인지 아닌지만 비교해놓고서, 갑자기 서로의 값 혹은 identity를 묻고서 그게 마치 "본질"인 것처럼 말하고 있는거죠. 논술세대가 아니신 것 같습니다만, 그래도 이정도 논리는 갖추어야 앞으로도 이로우실 겁니다. :) 그래도, 갈수록 유머감각 있으시네요. ㅋㅋ ㅎㅎㅎ 유머감각있으시네요. 지금 객체 타입으로서의 객체와 인스턴스로서의 객체를 혼동하고 계십니다. 으하하... 저라면 Function의 constructor가 Function으로 나올때부터 이상하다고 생각했을 텐데 그런 생각은 못하셨나봐요? 죄송하지만, 자바스크립트... 잘 모르시죠? 객체 타입이 Function의 인스턴스로 나타나는 것은 자바스크립트의 특징인 것입니다. 말하자면 class type1, class type2 를 지정하는 것과 같은 것이라는 말이죠. 그렇다고 type1과 type2 를 같은 클래스라고 하지는 않죠. 그게 바로 님께서 범한 오류입니다. 똑같이 class로 선언된다고 두개가 같은 클래스인가요? "클래스"라는 사실은 같겠죠. ㅋㅋ 객체 타입이 Function의 인스턴스로 나타나는 것은 자바스크립트의 특징, 그 중에서도 객체 타입선언의 특.수.성이라는 말입니다. 이러한 특수성을 가지고 마치 전체인양 호도하시다니 유머감각이 대단하시군요. ㅎㅎㅎ 제 말이 틀린 것이라면, 자료구조가 아닌 다른 인스턴스들을 한번 비교해보세요. ㅎㅎ 특수성이라는 말이 틀렸나요? 그러면 어떻게 Function의 생성자가 다시 Function이 될 수 있을지 한번 생각해보세요. 자료구조의 constructor를 비교해서 얘네가 다 Function이라고 말하는 것은 "얘네 모두 자료구조야"라는 말밖에 안된다는 겁니다. 아셨어요? ^^ 적어두세요. 특.수.성. constructor 한번 비교한 것은 그나마 봐줄 만 했습니다. constructor를 여러번 하면 당연히 최상위 객체가 나오겠죠. 그런데 상위객체를 비교해놓고서 "당신이 틀렸다"라고 하고 있으니, 상속의 개념... 잘 모르세요? 기껏 가져온다는 코드가 이런거라니... 참... 자, 이제... 생성자가 같고, 타입이 같고, 성질이 같은 두 객체가 어떻게 다르다고 볼 수 있는지 다시 말씀해보세요. 힘드셔서 그랬겠지만, 자료구조가 Function 객체라는 특수성을 가지고 호도할 생각은 마시고요. :) 요약 : 비교 자체가 틀려서 논할 가치도 없다. P.S1// 영어해석 딸리는 것은 알고있으니, 괘념치 마세요. P.S2// 방금은 쇼펜하우어 법칙 14번이네요. 역시 마스터하셨군요! _________________________________ 혹시 또 이해를 못하셨을까봐 님께서 하셨던 비유를 제가 설명해드리죠. var num1 = 1; var num2 = 2; alert(num1.constructor === num2.constructor); 이렇다고 num1과 num2의 "값"이 같은거냐고 묻고 있는겁니다. 두 객체의 indentity는 분명 다르고 값도 다르지만, "Number"의 특징을 지니고 있는 완전히 똑같은 "본질"(=숫자)의 객체임은 같은겁니다. 님께서 했던 그 코드는 말이죠. Array가 자료구조 맞아? Object가 자료구조 맞아? 이것만 비교한 것말고는 아무런 의미도 가지지 못한다는 거죠. Array === Object는 아니죠. identity도 다르고 값도 다르니까요. 하지만 "자료구조"임에는 확실히 맞습니다. 그게 Array와 Object의 "본질"이죠. 단지 "자료구조"인지 아닌지만 비교해놓고서, 갑자기 서로의 값 혹은 identity를 묻고서 그게 마치 "본질"인 것처럼 말하고 있는거죠. 논술세대가 아니신 것 같습니다만, 그래도 이정도 논리는 갖추어야 앞으로도 이로우실 겁니다. :) 그래도, 갈수록 유머감각 있으시네요. ㅋㅋ

숨어지내리   07-03-27 17:53   ㅋㅋㅋ 재미있군요.. 특수성이란 단어도 말씀하시고, 전 그냥 prototype chain으로 밖에는 안보이는데요. ..ㅋㅋ 전 고니님이 자바스크립트를 잘한다고 생각했었는데.. ------------------------------------------------------------------------------------ var obj1 = new Object; var obj2 = {}; alert(obj1.constructor === obj2.constructor); 의 결과는 true입니다. 두 객체의 생성자는 완전히 똑같은 객체이며 alert(obj1.constructor === Object); 에서 보다시피 그것은 Object 입니다. ------------------------------------------------------------------------------------- 3. Object 역시 Function의 인스턴스입니다.     따라서 객체타입으로서의 역할을 충분히 한다고 생각합니다 ------------------------------------------------------------------------------------- 지금 객체 타입으로서의 객체와 인스턴스로서의 객체를 혼동하고 계십니다. 으하하... ------------------------------------------------------------------------------------- 와 같이 주장하고 있는것은 Object 역시 Function 의 인스턴스라고 생각하시는분의 생각은 객체와 인스턴스로서의 객체를 잘 이해하고 있는것만은 아닌거 같은데요..^^ ㅋㅋㅋㅋ 자신의 논리로 자신의 논리를 부정하는것처럼 보여지는데요..^^ 전... constructor 로 Object 를 비교하면서 Object.constructor 로 표현하니 당연히 아니다라는 말인가? 그럼 고니님의 논리인 객체의 인스턴스로써의 constructor 로 표현하면 맞나요? ㅎㅎ alert(new Object().constructor.constructor === Function); alert(new Object().constructor.constructor === new Array().constructor.constructor); 돌려치나 매치나..ㅋㅋ constructor 로 비교하는것 자체가 고니님이 주장하는 게 틀린게 아닐까요?ㅎ 예제를 들어 표현한건데요..^^; 참 이상하게 받아들으시네..ㅋ 전 prototype chain 자체를 이해하지 못하는것처럼 보이는데요..^^ㅎㅎㅎ 고니님의 주장대로 하면 new Object() 의 본질은 Function 인가 봅니다. ㅎㅎ ps . 전 주장의 근거가 계속 바뀌는 고니님이 재미있는데요.. ㅎㅎ ps2. 개콘나가셔도 될듯하네요.. ㅎㅎㅎㅎ ㅋㅋㅋ 재미있군요.. 특수성이란 단어도 말씀하시고, 전 그냥 prototype chain으로 밖에는 안보이는데요. ..ㅋㅋ 전 고니님이 자바스크립트를 잘한다고 생각했었는데.. ------------------------------------------------------------------------------------ var obj1 = new Object; var obj2 = {}; alert(obj1.constructor === obj2.constructor); 의 결과는 true입니다. 두 객체의 생성자는 완전히 똑같은 객체이며 alert(obj1.constructor === Object); 에서 보다시피 그것은 Object 입니다. ------------------------------------------------------------------------------------- 3. Object 역시 Function의 인스턴스입니다. 따라서 객체타입으로서의 역할을 충분히 한다고 생각합니다 ------------------------------------------------------------------------------------- 지금 객체 타입으로서의 객체와 인스턴스로서의 객체를 혼동하고 계십니다. 으하하... ------------------------------------------------------------------------------------- 와 같이 주장하고 있는것은 Object 역시 Function 의 인스턴스라고 생각하시는분의 생각은 객체와 인스턴스로서의 객체를 잘 이해하고 있는것만은 아닌거 같은데요..^^ ㅋㅋㅋㅋ 자신의 논리로 자신의 논리를 부정하는것처럼 보여지는데요..^^ 전... constructor 로 Object 를 비교하면서 Object.constructor 로 표현하니 당연히 아니다라는 말인가? 그럼 고니님의 논리인 객체의 인스턴스로써의 constructor 로 표현하면 맞나요? ㅎㅎ alert(new Object().constructor.constructor === Function); alert(new Object().constructor.constructor === new Array().constructor.constructor); 돌려치나 매치나..ㅋㅋ constructor 로 비교하는것 자체가 고니님이 주장하는 게 틀린게 아닐까요?ㅎ 예제를 들어 표현한건데요..^^; 참 이상하게 받아들으시네..ㅋ 전 prototype chain 자체를 이해하지 못하는것처럼 보이는데요..^^ㅎㅎㅎ 고니님의 주장대로 하면 new Object() 의 본질은 Function 인가 봅니다. ㅎㅎ ps . 전 주장의 근거가 계속 바뀌는 고니님이 재미있는데요.. ㅎㅎ ps2. 개콘나가셔도 될듯하네요.. ㅎㅎㅎㅎ

행복한고니   07-03-27 19:05   숨어지내리 // 객체지향도 모르고, 타입으로서의 객체와 인스턴스로서의 객체를 혼동하고 계시니... 안타깝습니다. 어찌 그리 자기 주장만 보고 사시는지... ㅎㅎ Object, Array, Function, Date 등은 "객체타입"이라는 본질이 같은 겁니다. 아시겠습니까? 지금 님이 하신 행동은 말이죠. A라는 사람과 B라는 사람이 "사람"이라는 것을 증명해놓고 "둘 다 사람이라고 A와 B가 같은 사람이냐?" 라고 묻는 것과 같은 겁니다. 제가 증명하던게 그거였나요? 제가 증명하던 것은 A와 B가 둘 다 "사람"이라는 그 자체다 이겁니다. new Object와 {}의 constructor가 같아서 둘 다 같은 종류의 객체이며 값에 대한 특성은 굳이 따져보지 않아도 같음을 알지않습니까? new Object의 본질은 "Object"라는 것이고요, Object의 본질이 Function의 인스턴스로 표현되는 "객체타입"이라는 겁니다. 자바스크립트에는 타입의 Object 타입이 상위에 있는 것을 제외하고는 상속이 없습니다. 객체타입은 반드시 Function의 인스턴스가 되어야만 하죠. 따라서 현재 객체의 constructor는 인스턴스의 본질이 될 수 있지만, 어떠한 타입이라도 constructor를 두번 하게 되면 Function이 됩니다. 그 때는 하위객체와 상관없이 타입 객체 자체의 타입을 따지는거죠. constuctor를 두번 사용했다고 그 객체의 본질이 되는 것도 아니고, constructor를 따져보아 현재 인스턴스의 성질을 아는 겁니다. (new Object).constructor 를 하게되면 new Object 자체의 성질을 묻는 것이고, (new Object).constructor.constructor 를 하게되면 (new Object 타입객체라는 인스턴스)의 성질을 묻는 겁니다. 그냥 에러없이 실행되니까 헷갈리시죠? 이게 타입으로서인지 인스턴스로서인지도 모르고, 그냥 어찌어찌 봐도 말이 되는 것 같으니까 본인의 생각이 옳다고 생각하시는 모양인데, 그게 아니라 이겁니다. function 이 함수 자체로서도 사용할 수도 있고, 타입으로서 사용될 수도 있는 자바스크립트의 특징을 잘 이해나 하고 있나 모르겠군요. PS1// 추가로, 문법적인 차이말고 {}와 new Object가 어떻게 다른지는 근거가 없는 걸로 기억하는군요. 어설픈 우기기나 하지 마시고 본인의 주장이나 증명하세요. PS2// 걱정마세요. 전 자바스크립트만으로도 잘 먹고 잘 살고 있습니다. 숨어지내리 // 객체지향도 모르고, 타입으로서의 객체와 인스턴스로서의 객체를 혼동하고 계시니... 안타깝습니다. 어찌 그리 자기 주장만 보고 사시는지... ㅎㅎ Object, Array, Function, Date 등은 "객체타입"이라는 본질이 같은 겁니다. 아시겠습니까? 지금 님이 하신 행동은 말이죠. A라는 사람과 B라는 사람이 "사람"이라는 것을 증명해놓고 "둘 다 사람이라고 A와 B가 같은 사람이냐?" 라고 묻는 것과 같은 겁니다. 제가 증명하던게 그거였나요? 제가 증명하던 것은 A와 B가 둘 다 "사람"이라는 그 자체다 이겁니다. new Object와 {}의 constructor가 같아서 둘 다 같은 종류의 객체이며 값에 대한 특성은 굳이 따져보지 않아도 같음을 알지않습니까? new Object의 본질은 "Object"라는 것이고요, Object의 본질이 Function의 인스턴스로 표현되는 "객체타입"이라는 겁니다. 자바스크립트에는 타입의 Object 타입이 상위에 있는 것을 제외하고는 상속이 없습니다. 객체타입은 반드시 Function의 인스턴스가 되어야만 하죠. 따라서 현재 객체의 constructor는 인스턴스의 본질이 될 수 있지만, 어떠한 타입이라도 constructor를 두번 하게 되면 Function이 됩니다. 그 때는 하위객체와 상관없이 타입 객체 자체의 타입을 따지는거죠. constuctor를 두번 사용했다고 그 객체의 본질이 되는 것도 아니고, constructor를 따져보아 현재 인스턴스의 성질을 아는 겁니다. (new Object).constructor 를 하게되면 new Object 자체의 성질을 묻는 것이고, (new Object).constructor.constructor 를 하게되면 (new Object 타입객체라는 인스턴스)의 성질을 묻는 겁니다. 그냥 에러없이 실행되니까 헷갈리시죠? 이게 타입으로서인지 인스턴스로서인지도 모르고, 그냥 어찌어찌 봐도 말이 되는 것 같으니까 본인의 생각이 옳다고 생각하시는 모양인데, 그게 아니라 이겁니다. function 이 함수 자체로서도 사용할 수도 있고, 타입으로서 사용될 수도 있는 자바스크립트의 특징을 잘 이해나 하고 있나 모르겠군요. PS1// 추가로, 문법적인 차이말고 {}와 new Object가 어떻게 다른지는 근거가 없는 걸로 기억하는군요. 어설픈 우기기나 하지 마시고 본인의 주장이나 증명하세요. PS2// 걱정마세요. 전 자바스크립트만으로도 잘 먹고 잘 살고 있습니다.

행복한고니   07-03-27 19:15   prototype chain 이라는 단어를 잘 모르고 사용하시는 것 같아서 예제를 드리죠. 왜 constructor를 두번 이상하면 안되는지요. Function.prototype.aa = "aa"; Object.prototype.bb = "cc"; var obj = new Object; alert(Object.aa); alert(obj.aa); alert(obj.bb); 타입으로서의 객체와 인스턴스로의 객체타입을 혼동하지 마시기 바랍니다. prototype chain 이라는 단어를 잘 모르고 사용하시는 것 같아서 예제를 드리죠. 왜 constructor를 두번 이상하면 안되는지요. Function.prototype.aa = "aa"; Object.prototype.bb = "cc"; var obj = new Object; alert(Object.aa); alert(obj.aa); alert(obj.bb); 타입으로서의 객체와 인스턴스로의 객체타입을 혼동하지 마시기 바랍니다.

숨어지내리   07-03-27 20:00   ㅋㅋㅋ 아 2번하면 성질을 나타내는군요.. 고니님이 말하신 본질!! ----------------------------------------------------------------------------------------------------------- 지금 논리적인 착각을 하고 계시는 듯 해서 정리해드리면요. "용도"와 "모양"은 그 사물의 "본질"을 결정짓는 절대적인 요소가 아닙니다. 오히려 "성질"이 본질을 결정짓는 중요한 요소인거죠. ---------------------------------------------------------------------------------------------------------- A 가 B 와 같고 B 와 C 가 같다면 A != C 다르다고 생각하는 이유가 머죠? ㅎㅎㅎ new Object().constructor === Object 라고 본질을 주장하시는 분이 여태 본질을 물으려고 이렇게 예제를 보여주신거 아닌가요? 전 new Object().constructor.constructor == new Array().constructor.constructor 가 같으니, A = C 가 같아야 되는거 아닌가요? constructor 만으로 비교하시는것 자체가 잘못된거라 생각안하세요? new Object().constructor.constructor 의 1번 constructor 하는 것과 2번하는것의 차이가 있는줄 이제야 알았네요.. ㅋㅋㅋ constructor 라 지칭하는게 서로 다르다는 얘기네요..ㅋㅋㅋㅋㅋㅋㅋㅋ JAVASCRIPT 의 특수성이라 우기지 마세요..ㅋㅋㅋㅋㅋ 엄연히 prototype chain 이란 명이 있습니다. 전 prototype chain 의 특성이라 생각합니다. Object.prototype.a = "a"; alert(Array.a); alert(Function.a); alert(Number.a); alert(String.a); ㅋㅋ 인스턴스가 아닌 객체자신인데, 서로 통하네요..캬~ 이게 prototype chain 이 아닐까요? ㅋㅋ prototype chain 에 대해 더 공부하세요. 성질을 묻는다고 말하지도 마세요.... 공부하세요.!! ㅋㅋㅋㅋㅋㅋㅋ ps. 주관적인 생각을 심어주시네요..ㅋㅋ -------------------------------------- 자바스크립트에는 타입의 Object 타입이 상위에 있는 것을 제외하고는 상속이 없습니다. 객체타입은 반드시 Function의 인스턴스가 되어야만 하죠. -------------------------------------- 위의 것은 prototype chain 이란것으로 설명할수 있습니다. ㅋㅋ Object 가 최상위라는것은 이미 계속적으로 제가 말한 상태이고요..^^;ㅋㅋ ps2. ㅋㅋㅋ 이미 고니님의 주장은 설득력을 상실하였습니다. ps3. 개콘pd 분 소개시켜줘야겠다...ㅋㅋㅋㅋ ㅋㅋㅋ 아 2번하면 성질을 나타내는군요.. 고니님이 말하신 본질!! ----------------------------------------------------------------------------------------------------------- 지금 논리적인 착각을 하고 계시는 듯 해서 정리해드리면요. "용도"와 "모양"은 그 사물의 "본질"을 결정짓는 절대적인 요소가 아닙니다. 오히려 "성질"이 본질을 결정짓는 중요한 요소인거죠. ---------------------------------------------------------------------------------------------------------- A 가 B 와 같고 B 와 C 가 같다면 A != C 다르다고 생각하는 이유가 머죠? ㅎㅎㅎ new Object().constructor === Object 라고 본질을 주장하시는 분이 여태 본질을 물으려고 이렇게 예제를 보여주신거 아닌가요? 전 new Object().constructor.constructor == new Array().constructor.constructor 가 같으니, A = C 가 같아야 되는거 아닌가요? constructor 만으로 비교하시는것 자체가 잘못된거라 생각안하세요? new Object().constructor.constructor 의 1번 constructor 하는 것과 2번하는것의 차이가 있는줄 이제야 알았네요.. ㅋㅋㅋ constructor 라 지칭하는게 서로 다르다는 얘기네요..ㅋㅋㅋㅋㅋㅋㅋㅋ JAVASCRIPT 의 특수성이라 우기지 마세요..ㅋㅋㅋㅋㅋ 엄연히 prototype chain 이란 명이 있습니다. 전 prototype chain 의 특성이라 생각합니다. Object.prototype.a = "a"; alert(Array.a); alert(Function.a); alert(Number.a); alert(String.a); ㅋㅋ 인스턴스가 아닌 객체자신인데, 서로 통하네요..캬~ 이게 prototype chain 이 아닐까요? ㅋㅋ prototype chain 에 대해 더 공부하세요. 성질을 묻는다고 말하지도 마세요.... 공부하세요.!! ㅋㅋㅋㅋㅋㅋㅋ ps. 주관적인 생각을 심어주시네요..ㅋㅋ -------------------------------------- 자바스크립트에는 타입의 Object 타입이 상위에 있는 것을 제외하고는 상속이 없습니다. 객체타입은 반드시 Function의 인스턴스가 되어야만 하죠. -------------------------------------- 위의 것은 prototype chain 이란것으로 설명할수 있습니다. ㅋㅋ Object 가 최상위라는것은 이미 계속적으로 제가 말한 상태이고요..^^;ㅋㅋ ps2. ㅋㅋㅋ 이미 고니님의 주장은 설득력을 상실하였습니다. ps3. 개콘pd 분 소개시켜줘야겠다...ㅋㅋㅋㅋ

행복한고니   07-03-27 20:06   너무 길어졌군요. 다시 적어드리죠. 1. 일단 2차 상속이라는게 자바스크립트에는 없습니다. 설명은 위에서 밝혔으니 따로 하지 않겠습니다(코드만 봐도 충분하다 봅니다). 따라서 constructor 를 두번 비교하는 것은 위에서 제가 말했던 대로 님의 착각에서 비롯된 것입니다. 2. constructor 는 해당 인스턴스의 객체구조를 알 수 있게 합니다. 이 때 객체구조의 정의는 반드시 Function의 인스턴스여야 합니다. 3. Array, Date, Object 등은 객체구조로서 볼 때는 그저 구조를 정의한 객체타입일 뿐입니다. 그 자체가 인스턴스가 아닌 단지 타입이므로, "객체타입"이라는 본질에서 그들은 모두 같은 성질을 가지고 있습니다. 4. 자바스크립트에서는 객체타입이 곧 Function의 인스턴스이기도 하므로, 헷갈릴 수 있겠지만 Array, Date, Object 내장 객체자체의 데이터 구조는 다르지 않습니다. 다만 생성자 함수이기 때문에 이들이 정의하는 인스턴스들의 객체구조는 서로 다릅니다. 5. Array, Date, Object의 타입도 모두 같고, 이들이 서로 다른 객체구조를 정의하기 위해 사용되었을 지언정 인스턴스로서의 구조는 같습니다. 그것은 즉, Function 생성자에서 정의한 객체구조와 동일합니다. 6. new Object와 {}는 객체타입이 아니므로 인스턴스로서만 봅니다. 인스턴스로서만 봤을 때, new Object와 {}은 같은 생성자 Object에서 정의된 객체구조를 가집니다. 문법적인 차이만 있을 뿐 두가지는 서로 같습니다. 편의성을 위해 alias된 문법이 있다고 그게 본질을 결정하는 것은 아닙니다. 7. prototype 은 생성자에만 사용할 수 있으며, 생성자 함수로 생성될 인스턴스의 객체구조를 정의합니다. Object, Function 은 모두 생성자 함수이므로 prototype의 사용이 가능하지만, new Object는 prototype이라는 속성이 없습니다. 객체 타입인지, 인스턴스인지 헷갈려서 자신이 잘못이해한 것을 마치 진실인양 받아들이지 마시기 바랍니다. P.S// 위에서 Object.prototype 을 정의할 수 있는 것은 Object 객체 자체가 아니라 Object가 생성자 함수이기 때문입니다. 7번에 적은 이유때문이죠. prototype chain 의 의미를 잘 모르고 있다는 것은 이미 알고 있으니 다시 안 밝히셔도 됩니다. 너무 길어졌군요. 다시 적어드리죠. 1. 일단 2차 상속이라는게 자바스크립트에는 없습니다. 설명은 위에서 밝혔으니 따로 하지 않겠습니다(코드만 봐도 충분하다 봅니다). 따라서 constructor 를 두번 비교하는 것은 위에서 제가 말했던 대로 님의 착각에서 비롯된 것입니다. 2. constructor 는 해당 인스턴스의 객체구조를 알 수 있게 합니다. 이 때 객체구조의 정의는 반드시 Function의 인스턴스여야 합니다. 3. Array, Date, Object 등은 객체구조로서 볼 때는 그저 구조를 정의한 객체타입일 뿐입니다. 그 자체가 인스턴스가 아닌 단지 타입이므로, "객체타입"이라는 본질에서 그들은 모두 같은 성질을 가지고 있습니다. 4. 자바스크립트에서는 객체타입이 곧 Function의 인스턴스이기도 하므로, 헷갈릴 수 있겠지만 Array, Date, Object 내장 객체자체의 데이터 구조는 다르지 않습니다. 다만 생성자 함수이기 때문에 이들이 정의하는 인스턴스들의 객체구조는 서로 다릅니다. 5. Array, Date, Object의 타입도 모두 같고, 이들이 서로 다른 객체구조를 정의하기 위해 사용되었을 지언정 인스턴스로서의 구조는 같습니다. 그것은 즉, Function 생성자에서 정의한 객체구조와 동일합니다. 6. new Object와 {}는 객체타입이 아니므로 인스턴스로서만 봅니다. 인스턴스로서만 봤을 때, new Object와 {}은 같은 생성자 Object에서 정의된 객체구조를 가집니다. 문법적인 차이만 있을 뿐 두가지는 서로 같습니다. 편의성을 위해 alias된 문법이 있다고 그게 본질을 결정하는 것은 아닙니다. 7. prototype 은 생성자에만 사용할 수 있으며, 생성자 함수로 생성될 인스턴스의 객체구조를 정의합니다. Object, Function 은 모두 생성자 함수이므로 prototype의 사용이 가능하지만, new Object는 prototype이라는 속성이 없습니다. 객체 타입인지, 인스턴스인지 헷갈려서 자신이 잘못이해한 것을 마치 진실인양 받아들이지 마시기 바랍니다. P.S// 위에서 Object.prototype 을 정의할 수 있는 것은 Object 객체 자체가 아니라 Object가 생성자 함수이기 때문입니다. 7번에 적은 이유때문이죠. prototype chain 의 의미를 잘 모르고 있다는 것은 이미 알고 있으니 다시 안 밝히셔도 됩니다.

무소레즈   07-03-27 20:08   constructor의 객체타입이 같다고 instance 개체가 같다고 할 수는 없지 않을까 합니다. instance 는 같아도 constructor 는 달라질 수 있습니다. 엄밀히 말하자면, instance 는 같아도 instance 개체는 다릅니다. 같은 instance 라해도  실체화된 instance 개체의 constructor 는 달라질 수 있기때문입니다. instance 개체 생성시 실행되는 객체 함수내부에서의 초기 조건에따라 서로 다른 생성자를 가진 서로다른 instance 개체가 생성될 수 있습니다. 예를 들어, 임의 빈 함수 price 를 만들고  new 를 통하여 meat 라는 임의 개체변수로 instance 개체를 생성하면 meat 의 constructor 는 함수타입의 price 가 되고 meat 의 instance 는 함수객체 price 타입의 instance 이기도 하며 또한 new 를 통해 생성하였기에 Object 타입 의 instance 이기도 합니다. 하지만, function price(cond) {     if(cond) this.constructor=(new Date).constructor;     else this.constructor=(new Function).constructor;     return this; } var meat1=price(0); var meat2=price(1); 으로 instance 개체 두개를 생성했을때.. meat1 과 meat2  의 instance 를 보면, price 객체타입의 instance 이며, Object 객체타입의 instance 이기도 합니다. 같은 instance 를 갖기만  instance 개체가 같다는 말은 아닙니다. meat1 의 constructor 는 Date 함수 객체타입이지만 meat2 의 constructor 는 Function 함수 객체타입이 됩니다. constructor 는 다르지만 instance 가 같습니다. 다시한번 얘기하지만 instance 가 같다는 것이   instance 개체가 같다는 의미는 전혀 아닙니다. instance 라는 것은 constructor 함수 내부의 조건별 환경과는 무관하게 instance 개체 생성시에 어떤 객체타입의 instance 인가만을 알려준다는 것입니다. constructor 체크와 instance 체크는 단지 어떤 객체타입의 constructor 인가, 또는 어느 객체타입의 instance 를 가졌는가를 확인하기위한 것일뿐 실체로서의 instance 개체의 동질성을 판단해주지는 못합니다. instance 는 같을 수 있을지라도 instance 개체는 분명히 다릅니다. 또한, 사용자 정의 함수 객체의 내부 제어에따라 instance 까지도 변경이 가능합니다. constructor의 객체타입이 같다고 instance 개체가 같다고 할 수는 없지 않을까 합니다. instance 는 같아도 constructor 는 달라질 수 있습니다. 엄밀히 말하자면, instance 는 같아도 instance 개체는 다릅니다. 같은 instance 라해도 실체화된 instance 개체의 constructor 는 달라질 수 있기때문입니다. instance 개체 생성시 실행되는 객체 함수내부에서의 초기 조건에따라 서로 다른 생성자를 가진 서로다른 instance 개체가 생성될 수 있습니다. 예를 들어, 임의 빈 함수 price 를 만들고 new 를 통하여 meat 라는 임의 개체변수로 instance 개체를 생성하면 meat 의 constructor 는 함수타입의 price 가 되고 meat 의 instance 는 함수객체 price 타입의 instance 이기도 하며 또한 new 를 통해 생성하였기에 Object 타입 의 instance 이기도 합니다. 하지만, function price(cond) { if(cond) this.constructor=(new Date).constructor; else this.constructor=(new Function).constructor; return this; } var meat1=price(0); var meat2=price(1); 으로 instance 개체 두개를 생성했을때.. meat1 과 meat2 의 instance 를 보면, price 객체타입의 instance 이며, Object 객체타입의 instance 이기도 합니다. 같은 instance 를 갖기만 instance 개체가 같다는 말은 아닙니다. meat1 의 constructor 는 Date 함수 객체타입이지만 meat2 의 constructor 는 Function 함수 객체타입이 됩니다. constructor 는 다르지만 instance 가 같습니다. 다시한번 얘기하지만 instance 가 같다는 것이 instance 개체가 같다는 의미는 전혀 아닙니다. instance 라는 것은 constructor 함수 내부의 조건별 환경과는 무관하게 instance 개체 생성시에 어떤 객체타입의 instance 인가만을 알려준다는 것입니다. constructor 체크와 instance 체크는 단지 어떤 객체타입의 constructor 인가, 또는 어느 객체타입의 instance 를 가졌는가를 확인하기위한 것일뿐 실체로서의 instance 개체의 동질성을 판단해주지는 못합니다. instance 는 같을 수 있을지라도 instance 개체는 분명히 다릅니다. 또한, 사용자 정의 함수 객체의 내부 제어에따라 instance 까지도 변경이 가능합니다.

숨어지내리   07-03-27 20:11   동의 합니다.!! 동의 합니다.!!

행복한고니   07-03-27 20:17   아래글 다 안읽고 동의하시면 후회할 겁니다. :) 아래글 다 안읽고 동의하시면 후회할 겁니다. :)

숨어지내리   07-03-27 20:24   ㅋㅋㅋㅋㅋㅋ 네 :) ㅋㅋㅋㅋㅋㅋ 네 :)

행복한고니   07-03-27 20:27   아.. .윗글에 자바스크립트의 특성에 대해서 간략하게 썼으니 보고 공부하세요. 모르는 건 죄가 아니지만, 모르면서도 안다고 우기는 것은 좋지 않죠. 아.. .윗글에 자바스크립트의 특성에 대해서 간략하게 썼으니 보고 공부하세요. 모르는 건 죄가 아니지만, 모르면서도 안다고 우기는 것은 좋지 않죠.

숨어지내리   07-03-27 20:37   ㅋㅋㅋㅋㅋㅋㅋ 네 :) ㅋㅋㅋㅋㅋㅋㅋ 네 :)

행복한고니   07-03-27 20:16   예제가 잘못되었습니다. 내장 메소드, 객체까지 덮어씌울 수 있는 자바스크립트의 특성상 그렇게 보일 뿐입니다. return this 하기전에, this.constructor = 1; 도 해보세요. 되나 안되나. ^^ 그리고 price(0) <- 이렇게 한 것은 price가 객체의 생성자로서 사용된 것이 아닌 단순한 함수의 실행입니다. 단순한 함수의 실행은 생성자 함수로서 인정밭지 못하기 때문에 this가 가리키는 것은 함수자체가 아닌 window 객체가 됩니다. price.prototype을 해도 그곳에 정의된 자료구조가 meat1에는 적용되지 않는 것도 물론이고요. 제 말이 맞는지 틀린지 테스트해보세요. this.constructor 가 덮어씌워져서 그렇게 되는 것처럼 보일 뿐입니다. 무소레즈님께서 작성한 코드 아래에 다음과 같이 실행해보세요. ^^ alert(meat1.constructor); alert(meat2.constructor); meat1과 meat2는 독립적인 객체도 아닐 뿐더러 price에 의해 생성된 인스턴스는 더더군다나 아닙니다. 아... 그리고 덮어씌웠다고 한들 그게 생성자로서의 역할을 하는 것도 아닙니다. var obj = new Object; alert(obj.__proto__ === Object.prototype); 이지만 위 예제에서 meat1.constructor === Date.prototype 은 아닙니다. constructor가 그 인스턴스 객체의 성질과 자료구조를 결정짓는 겁니다. 예제가 잘못되었습니다. 내장 메소드, 객체까지 덮어씌울 수 있는 자바스크립트의 특성상 그렇게 보일 뿐입니다. return this 하기전에, this.constructor = 1; 도 해보세요. 되나 안되나. ^^ 그리고 price(0) <- 이렇게 한 것은 price가 객체의 생성자로서 사용된 것이 아닌 단순한 함수의 실행입니다. 단순한 함수의 실행은 생성자 함수로서 인정밭지 못하기 때문에 this가 가리키는 것은 함수자체가 아닌 window 객체가 됩니다. price.prototype을 해도 그곳에 정의된 자료구조가 meat1에는 적용되지 않는 것도 물론이고요. 제 말이 맞는지 틀린지 테스트해보세요. this.constructor 가 덮어씌워져서 그렇게 되는 것처럼 보일 뿐입니다. 무소레즈님께서 작성한 코드 아래에 다음과 같이 실행해보세요. ^^ alert(meat1.constructor); alert(meat2.constructor); meat1과 meat2는 독립적인 객체도 아닐 뿐더러 price에 의해 생성된 인스턴스는 더더군다나 아닙니다. 아... 그리고 덮어씌웠다고 한들 그게 생성자로서의 역할을 하는 것도 아닙니다. var obj = new Object; alert(obj.__proto__ === Object.prototype); 이지만 위 예제에서 meat1.constructor === Date.prototype 은 아닙니다. constructor가 그 인스턴스 객체의 성질과 자료구조를 결정짓는 겁니다.

무소레즈   07-03-27 20:30   글 작성시 소스를 제대로 작성치 못했군요... 수정합니다. function price(cond) {     if(cond) this.constructor=(new Date).constructor;     else this.constructor=(new Function).constructor;     return this; } var meat1=new price(0); var meat2=new price(1); 이것이 맞습니다. 다시 테스트 해보시지요. 글 작성시 소스를 제대로 작성치 못했군요... 수정합니다. function price(cond) { if(cond) this.constructor=(new Date).constructor; else this.constructor=(new Function).constructor; return this; } var meat1=new price(0); var meat2=new price(1); 이것이 맞습니다. 다시 테스트 해보시지요.

행복한고니   07-03-27 20:34   그게... 위에서도 말했지만, 프로퍼티를 재정의할 수 있는 자바스크립트의 특성때문입니다. return this 위에 this.constructor=1 이라고 해도 된다고 말씀도 드렸는데요. ^^;; alert(meat1 instanceof Date); alert(meat1 instanceof price); 설령 constructor라는 속성을 재정의 한 것처럼 보일지라도 meat1은 여전히 price의 인스턴스입니다. 그게... 위에서도 말했지만, 프로퍼티를 재정의할 수 있는 자바스크립트의 특성때문입니다. return this 위에 this.constructor=1 이라고 해도 된다고 말씀도 드렸는데요. ^^;; alert(meat1 instanceof Date); alert(meat1 instanceof price); 설령 constructor라는 속성을 재정의 한 것처럼 보일지라도 meat1은 여전히 price의 인스턴스입니다.

무소레즈   07-03-27 21:18   instance 와  instance 개체가 다르다는 것에대해 얘기를 했고, 그와 관련되 예문을 보여 드린것인데 instance 가 다르다느니 하는 얘기는 엉뚱하게 들립니다. instance 가 같아도 instance 개체는 항상 같지 않다는 것에대해 얘기한것입니다. instance 와 instance 개체를 혼동하지 않았으면 하는 의미였지요. 추측을 기반으로 참여하였지만, 재미도 있겠다 싶어 시작한 얘기들이 말하고자 하는 바에대한 얘기를 벗어나는 댓글만 나오는것 같군요. instance 와 instance 개체가 다르다는 것에대해 얘기를 했고, 그와 관련되 예문을 보여 드린것인데 instance 가 다르다느니 하는 얘기는 엉뚱하게 들립니다. instance 가 같아도 instance 개체는 항상 같지 않다는 것에대해 얘기한것입니다. instance 와 instance 개체를 혼동하지 않았으면 하는 의미였지요. 추측을 기반으로 참여하였지만, 재미도 있겠다 싶어 시작한 얘기들이 말하고자 하는 바에대한 얘기를 벗어나는 댓글만 나오는것 같군요.

행복한고니   07-03-27 21:26   무슨 말씀인지 이해가 안됩니다. price 는 meat1의 생성자이고 meat1은 price의 인스턴스입니다. 이 사실은 설령 meat1의 constructor 속성이 재정의 된 것처럼 보이더라도 변하지 않습니다. 재정의 된 것처럼 보일 뿐 실제로 instanceof 등의 연산자로 체크해보면 변하지 않았음을 알 수 있습니다. 용어혼동이 와서 그러는데, 클래스/인스턴스 혹은 객체타입/인스턴스 라는 용어로 다시 정리해주시겠습니까? "instance" 와 "instance 개체"가 각각 의미하는 것이 무엇인지 애매하네요. 자바스크립트는 미리 정의된 속성도 재정의 할 수 있는 무척 유연한 언어입니다. constructor 속성을 강제로 재정의 한 것이 그게 재정의 된 것처럼 보일지라도 실제로 내부적으로는 재정의가 된 것이 아니라는 의미로 코드를 드렸습니다. 그래서 , constructor 속성을 재정의 했을지라도 여전히 meat1은 price의 인스턴스임을 증명해드렸습니다. 무엇이 벗어났다는 것인지 모르겠습니다. 무슨 말씀인지 이해가 안됩니다. price 는 meat1의 생성자이고 meat1은 price의 인스턴스입니다. 이 사실은 설령 meat1의 constructor 속성이 재정의 된 것처럼 보이더라도 변하지 않습니다. 재정의 된 것처럼 보일 뿐 실제로 instanceof 등의 연산자로 체크해보면 변하지 않았음을 알 수 있습니다. 용어혼동이 와서 그러는데, 클래스/인스턴스 혹은 객체타입/인스턴스 라는 용어로 다시 정리해주시겠습니까? "instance" 와 "instance 개체"가 각각 의미하는 것이 무엇인지 애매하네요. 자바스크립트는 미리 정의된 속성도 재정의 할 수 있는 무척 유연한 언어입니다. constructor 속성을 강제로 재정의 한 것이 그게 재정의 된 것처럼 보일지라도 실제로 내부적으로는 재정의가 된 것이 아니라는 의미로 코드를 드렸습니다. 그래서 , constructor 속성을 재정의 했을지라도 여전히 meat1은 price의 인스턴스임을 증명해드렸습니다. 무엇이 벗어났다는 것인지 모르겠습니다.

숨어지내리   07-03-27 21:32   ㅋㅋㅋㅋㅋㅋ 재미있군요..^^; 이렇게 까지는 하기 싫었는데.. --------------------------------------------------------------------------------------------------------------------------- PS1// 추가로, 문법적인 차이말고 {}와 new Object가 어떻게 다른지는 근거가 없는 걸로 기억하는군요. 어설픈 우기기나 하지 마시고 본인의 주장이나 증명하세요. PS2// 걱정마세요. 전 자바스크립트만으로도 잘 먹고 잘 살고 있습니다. --------------------------------------------------------------------------------------------------------------------------- 고니님은 new Object() === {} 는 같다. 라고 하셨는데.. 완전히 주관이었던게 드러났습니다. delete Object; alert({});                alert(new Object()); 위의 코드가 증명해 주고 있습니다. 아까도 말했듯이 constructor 로 비교하는것 자체가 무리가 있다고 하지 않았나요? ㅋㅋㅋㅋ 참 재미있는 토론입니다. !! 아니 말장난입니다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아.. 고니님 먹고 살기 힘드시겠습니다... ㅋㅋㅋ 객체를 삭제하면 new Object() 는 에러가 납니다. 허나 literal 은 본연의 임무를 충실히 시행하네요. .ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아직도 자기 주관을 남에게 이관시킬 작정입니까? ㅋㅋㅋㅋ 저것도 반문해 보시지요??? 저것도 JAVASCRIPT 의 특징 아니!! 특.수.성 입니까???????????????????????? 또 본질은 같다? ㅋㅋㅋㅋㅋㅋㅋ 자신의 우둔함과 교만, 주장을 남에게 설파하는것밖으로는 안보이는군요. 믿어라 믿는자에게 복이 있나니..ㅋㅋㅋ ps. 자.. 행복한 고니님을 개콘으로~ ps2. 저 JAVASCRIPT 잘못합니다. ^^; 헌데.. 고니님도 못하시는듯 합니다. ㅋㅋ ps3. 정말 이렇게 까진 하기싫었지만, 전 고니님이 다음의 내용을 실천하시거라 생각합니다. ----------------------------- 아뇨. 정말로 틀렸다는 것을 증명해주시기를 바라고 있습니다. 원하신다면 문서로 만들어서 대중의 심판을 받을 각오도 되어있습니다. 여태까지 주신 근거는 제가 아니라고 반박해드렸습니다. 애매한 태도로 제가 우긴 것처럼 하지 마시고요, 정확하게 논거를 들어주시기 바랍니다. 틀렸으면 깨끗이 인정을 하시던가 그렇지 않으면 "내부적으로는 다르다" 는 것에 대한 증거를 보여주셨으면 합니다. 지금과 같은 태도는 별로 바람직하지 않다고 봅니다. 본질을 흐렸다고 생각하지 않고 있는데, 본질은 무엇이며 어떻게 흐렸는지도 좀 알려주시고요. 인정하기 싫으신건지는 모르겠지만, 어쨌든 간곡히 부탁드립니다 ------------------------------- ㅋㅋㅋㅋㅋㅋ 재미있군요..^^; 이렇게 까지는 하기 싫었는데.. --------------------------------------------------------------------------------------------------------------------------- PS1// 추가로, 문법적인 차이말고 {}와 new Object가 어떻게 다른지는 근거가 없는 걸로 기억하는군요. 어설픈 우기기나 하지 마시고 본인의 주장이나 증명하세요. PS2// 걱정마세요. 전 자바스크립트만으로도 잘 먹고 잘 살고 있습니다. --------------------------------------------------------------------------------------------------------------------------- 고니님은 new Object() === {} 는 같다. 라고 하셨는데.. 완전히 주관이었던게 드러났습니다. delete Object; alert({}); alert(new Object()); 위의 코드가 증명해 주고 있습니다. 아까도 말했듯이 constructor 로 비교하는것 자체가 무리가 있다고 하지 않았나요? ㅋㅋㅋㅋ 참 재미있는 토론입니다. !! 아니 말장난입니다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아.. 고니님 먹고 살기 힘드시겠습니다... ㅋㅋㅋ 객체를 삭제하면 new Object() 는 에러가 납니다. 허나 literal 은 본연의 임무를 충실히 시행하네요. .ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아직도 자기 주관을 남에게 이관시킬 작정입니까? ㅋㅋㅋㅋ 저것도 반문해 보시지요??? 저것도 JAVASCRIPT 의 특징 아니!! 특.수.성 입니까???????????????????????? 또 본질은 같다? ㅋㅋㅋㅋㅋㅋㅋ 자신의 우둔함과 교만, 주장을 남에게 설파하는것밖으로는 안보이는군요. 믿어라 믿는자에게 복이 있나니..ㅋㅋㅋ ps. 자.. 행복한 고니님을 개콘으로~ ps2. 저 JAVASCRIPT 잘못합니다. ^^; 헌데.. 고니님도 못하시는듯 합니다. ㅋㅋ ps3. 정말 이렇게 까진 하기싫었지만, 전 고니님이 다음의 내용을 실천하시거라 생각합니다. ----------------------------- 아뇨. 정말로 틀렸다는 것을 증명해주시기를 바라고 있습니다. 원하신다면 문서로 만들어서 대중의 심판을 받을 각오도 되어있습니다. 여태까지 주신 근거는 제가 아니라고 반박해드렸습니다. 애매한 태도로 제가 우긴 것처럼 하지 마시고요, 정확하게 논거를 들어주시기 바랍니다. 틀렸으면 깨끗이 인정을 하시던가 그렇지 않으면 "내부적으로는 다르다" 는 것에 대한 증거를 보여주셨으면 합니다. 지금과 같은 태도는 별로 바람직하지 않다고 봅니다. 본질을 흐렸다고 생각하지 않고 있는데, 본질은 무엇이며 어떻게 흐렸는지도 좀 알려주시고요. 인정하기 싫으신건지는 모르겠지만, 어쨌든 간곡히 부탁드립니다 -------------------------------

행복한고니   07-03-27 21:41   브라우저를 IE만 쓰시나봐요? 여태까지는 Mozilla 에만 있는 set, get 을 특징으로 드시더니요? ^^ FF에서 해보세요. :) 아... 참고로 모질라 재단에 자바스크립트의 창시자인 Brendan Eich 씨가 있는 것은 아시죠? 게다가 IE에서 사용되는 것은 자기들도 스스로 JavaScript가 아닌 JScript 라 부른다는 사실~ 아시고 계시죠? ^^ 테스트 할 때는 좀 다양하게 해보세요. 제일 처음의 코드부터, Create by도 딸랑 하나만 보고 근거로 삼질 않나, 이번에도 딸랑 IE에서만 해보고 "앗싸, 이거다"라는 마음에 테스트도 안해보고... ㅎㅎ PS// 제가 님보다 많이 벌걸요? 제 생계는 걱정마세요. ^^ 브라우저를 IE만 쓰시나봐요? 여태까지는 Mozilla 에만 있는 set, get 을 특징으로 드시더니요? ^^ FF에서 해보세요. :) 아... 참고로 모질라 재단에 자바스크립트의 창시자인 Brendan Eich 씨가 있는 것은 아시죠? 게다가 IE에서 사용되는 것은 자기들도 스스로 JavaScript가 아닌 JScript 라 부른다는 사실~ 아시고 계시죠? ^^ 테스트 할 때는 좀 다양하게 해보세요. 제일 처음의 코드부터, Create by도 딸랑 하나만 보고 근거로 삼질 않나, 이번에도 딸랑 IE에서만 해보고 "앗싸, 이거다"라는 마음에 테스트도 안해보고... ㅎㅎ PS// 제가 님보다 많이 벌걸요? 제 생계는 걱정마세요. ^^

숨어지내리   07-03-27 21:47   ㅋㅋㅋㅋㅋ 아직도 인정을 안하시네..ㅋㅋ 고집하나 대단 하십니다..ㅋㅋㅋ Brendan Eich 이분이 M$로 가면 말이 되는건가요? ㅋㅋㅋㅋㅋㅋㅋ 논리적인 부분의 비약이 드러납니다.ㅋ ㅋㅋㅋㅋㅋ 아직도 인정을 안하시네..ㅋㅋ 고집하나 대단 하십니다..ㅋㅋㅋ Brendan Eich 이분이 M$로 가면 말이 되는건가요? ㅋㅋㅋㅋㅋㅋㅋ 논리적인 부분의 비약이 드러납니다.ㅋ

행복한고니   07-03-27 21:52   Mozilla specific 은 누가 먼저 예로 들었는지 말안해도 아실텐데요? :) 게다가 우리가 서로 근거로 삼고 있는 문서또한 MDC 문서였구요. http://en.wikipedia.org/wiki/JScript JScript는 Microsoft에서 만든 ECMA 스크립트 언어의 하나로 "Approx. JavaScript" 라고만 나와있습니다. 자신의 근거가 힘을 받지 못하니 "제 고집"이 되는거군요. 자신이 끈질기게 근거로 들었던 부분이 얼마나 JScript와 호환되는지부터 살펴보고 그런 말씀을 해주세요. 우리 지금 javascript 에 대해서 말하고 있는 게 아니었나요? 참 재밌군요. 저 승리감에 도취된 말투라니... ㅎㅎ 아.. Eich 씨요.. 모질라의 CTO 이십니다. ^^ ______________________________________________ 자기가 모질라에서만 특징적인 것으로 근거를 들 때는 그게 논리적인 근거가 되고, 제가 IE는 JScript는 JavaScript가 아니다라고 하니까 고집이 되는군요. 내가 하면 로맨스, 남이 하면 불륜? ㅎㅎ 더 그럴 듯 한걸로 가져오세요. 이제 다 떨어졌나요? ^^ Mozilla specific 은 누가 먼저 예로 들었는지 말안해도 아실텐데요? :) 게다가 우리가 서로 근거로 삼고 있는 문서또한 MDC 문서였구요. http://en.wikipedia.org/wiki/JScript JScript는 Microsoft에서 만든 ECMA 스크립트 언어의 하나로 "Approx. JavaScript" 라고만 나와있습니다. 자신의 근거가 힘을 받지 못하니 "제 고집"이 되는거군요. 자신이 끈질기게 근거로 들었던 부분이 얼마나 JScript와 호환되는지부터 살펴보고 그런 말씀을 해주세요. 우리 지금 javascript 에 대해서 말하고 있는 게 아니었나요? 참 재밌군요. 저 승리감에 도취된 말투라니... ㅎㅎ 아.. Eich 씨요.. 모질라의 CTO 이십니다. ^^ ______________________________________________ 자기가 모질라에서만 특징적인 것으로 근거를 들 때는 그게 논리적인 근거가 되고, 제가 IE는 JScript는 JavaScript가 아니다라고 하니까 고집이 되는군요. 내가 하면 로맨스, 남이 하면 불륜? ㅎㅎ 더 그럴 듯 한걸로 가져오세요. 이제 다 떨어졌나요? ^^

숨어지내리   07-03-27 21:57   "재밌네요. 어거지도 이만하면 상줄만 합니다. " 이말이 생각납니다. "재밌네요. 어거지도 이만하면 상줄만 합니다. " 이말이 생각납니다.

행복한고니   07-03-27 22:02   저는 위에서 적은 말 말고도 "똥묻은 개가 겨묻은 개 나무란다"는 말이 생각나는군요. 기껏 근거로 드는 코드라는게 인스턴스와 생성자로서의 역할도 모르고, 상속도 모르고, prototype chain에 대한 이해도 없이 자신이 헷갈려놓고 마치 진실인 양 하더니, 이제는 JScript 에 있는 특징을 보고 "이게 Javascript의 진실이다"라고 하질 않나, 자신이 저~~ 위에서부터 set, get 과 같은 Mozill에 특징적인 스펙을 설명할 때는, MDC의 문서를 근거로 들 때는 생각지도 못하고 이제와서 JScript의 스펙이라고 말하는 사람에게 "고집"이라는 둥, "어거지"라는 둥, 억울하면 증명하세요. 저는 위에서 적은 말 말고도 "똥묻은 개가 겨묻은 개 나무란다"는 말이 생각나는군요. 기껏 근거로 드는 코드라는게 인스턴스와 생성자로서의 역할도 모르고, 상속도 모르고, prototype chain에 대한 이해도 없이 자신이 헷갈려놓고 마치 진실인 양 하더니, 이제는 JScript 에 있는 특징을 보고 "이게 Javascript의 진실이다"라고 하질 않나, 자신이 저~~ 위에서부터 set, get 과 같은 Mozill에 특징적인 스펙을 설명할 때는, MDC의 문서를 근거로 들 때는 생각지도 못하고 이제와서 JScript의 스펙이라고 말하는 사람에게 "고집"이라는 둥, "어거지"라는 둥, 억울하면 증명하세요.

숨어지내리   07-03-27 22:01   전, 일관된 주장...  new Object() 와 {} 가 똑같을지 의문이 듭니다. ㅋㅋㅋ 비슷하다, 동일하다, 하는역할이 같다, 인스턴스를 반환한다. 정도이지, 똑같다라는 표현 ... 참 어색하기 그지없습니다. .ㅡㅡ;ㅋㅋ 전, 일관된 주장... new Object() 와 {} 가 똑같을지 의문이 듭니다. ㅋㅋㅋ 비슷하다, 동일하다, 하는역할이 같다, 인스턴스를 반환한다. 정도이지, 똑같다라는 표현 ... 참 어색하기 그지없습니다. .ㅡㅡ;ㅋㅋ

행복한고니   07-03-27 22:06   저도 일관된 주장. {}는 new Object 를 편하게 사용하기 위한(특히 property를 설정할 때), 문법적인 alias일 뿐이다. new Function 객체가 있어도 function 선언으로 함수를 만들 수 있죠. 하지만 뭘로 만들건 같은 특징과 성질을 가지는 "함수"일 뿐입니다. 용도는 달라도, 문법적인 모양은 달라도 결국은 똑같은 "함수", 똑같은 "Object". 문법적인 차이는 3살짜리 꼬맹이가 봐도 생긴게 다르니 당연히 다르죠. 하지만 "본질" 혹은 "특징"이 다르다는 근거는 아직 못봤네요. 계속 일관된 고집만 보여요. ___________________________ 아... 개콘 PD 아시면 방청권 하나 부탁합니다. 아직 가본적이 없네요. :) 저도 일관된 주장. {}는 new Object 를 편하게 사용하기 위한(특히 property를 설정할 때), 문법적인 alias일 뿐이다. new Function 객체가 있어도 function 선언으로 함수를 만들 수 있죠. 하지만 뭘로 만들건 같은 특징과 성질을 가지는 "함수"일 뿐입니다. 용도는 달라도, 문법적인 모양은 달라도 결국은 똑같은 "함수", 똑같은 "Object". 문법적인 차이는 3살짜리 꼬맹이가 봐도 생긴게 다르니 당연히 다르죠. 하지만 "본질" 혹은 "특징"이 다르다는 근거는 아직 못봤네요. 계속 일관된 고집만 보여요. ___________________________ 아... 개콘 PD 아시면 방청권 하나 부탁합니다. 아직 가본적이 없네요. :)

숨어지내리   07-03-27 22:27   ㅋㅋ 또, 문법적인 alias 로 되어 있네요.. ^^;; 매회 바뀌는 주장들... 이젠 고만하시죠. 읽는 분들에게 뭇매 맞습니다. ㅡㅡ; 전 판단은 읽으신 분들이 하실거라 생각합니다. 전 할만큼 다했습니다. ^^;;;;;;;;;;;ㅋㅋㅋㅋㅋ 똑같다라는 표현... 이젠 자제해 주세요. http://zeldign.com/tt/38 위의 입장이니, 보시는분들에게 판단을 돌리죠 ? 고니님..^^; 참고: http://zeldign.com/tt/39         액션스크립트에서 {} 과 new Object() 퍼포먼스 테스트한 결과라는데,         다들 참고하시면 좋을거 같네요. ^^.         이건 테스트한 분의 주관이 포함된 것이니, 알아서들 판단하셔야 합니다.^^ ㅋㅋ 또, 문법적인 alias 로 되어 있네요.. ^^;; 매회 바뀌는 주장들... 이젠 고만하시죠. 읽는 분들에게 뭇매 맞습니다. ㅡㅡ; 전 판단은 읽으신 분들이 하실거라 생각합니다. 전 할만큼 다했습니다. ^^;;;;;;;;;;;ㅋㅋㅋㅋㅋ 똑같다라는 표현... 이젠 자제해 주세요. http://zeldign.com/tt/38 위의 입장이니, 보시는분들에게 판단을 돌리죠 ? 고니님..^^; 참고: http://zeldign.com/tt/39 액션스크립트에서 {} 과 new Object() 퍼포먼스 테스트한 결과라는데, 다들 참고하시면 좋을거 같네요. ^^. 이건 테스트한 분의 주관이 포함된 것이니, 알아서들 판단하셔야 합니다.^^

행복한고니   07-03-27 22:32   제 글 안 읽으시는군요. alias는 저~~~기 위에도 있습니다. 이 페이지에서 alias로 검색해보세요. 저는 말과 행동이 다른 누군가가 아니라서요. ^^ 과연 이제 정말로 안오려나... ㅋㅋ 또 두고보죠 뭐 제가 왜 자제하죠? 저도 할만큼 했는데요. "내부적으로 다르다"라는 명제를 증명하지 못한 사람은 제가 아닌걸요? :) 그냥 그렇게 생각하고 사시라는 말, 또 합니다. 그냥 그렇게 생각하고 사세요. 결론 : {}과 new Object는 똑같은 표현입니다. // JScript를 JavaScript로 보고 "증명해냈다"라고 하는 모습이, 참...-_-;; 제 글 안 읽으시는군요. alias는 저~~~기 위에도 있습니다. 이 페이지에서 alias로 검색해보세요. 저는 말과 행동이 다른 누군가가 아니라서요. ^^ 과연 이제 정말로 안오려나... ㅋㅋ 또 두고보죠 뭐 제가 왜 자제하죠? 저도 할만큼 했는데요. "내부적으로 다르다"라는 명제를 증명하지 못한 사람은 제가 아닌걸요? :) 그냥 그렇게 생각하고 사시라는 말, 또 합니다. 그냥 그렇게 생각하고 사세요. 결론 : {}과 new Object는 똑같은 표현입니다. // JScript를 JavaScript로 보고 "증명해냈다"라고 하는 모습이, 참...-_-;;

숨어지내리   07-03-27 22:45   ㅋㅋㅋㅋㅋㅋ 네 :) 고니님의 주장 적절히 판단하겠습니다. ^^ 수고하셨습니다. ㅋㅋㅋㅋㅋㅋ 네 :) 고니님의 주장 적절히 판단하겠습니다. ^^ 수고하셨습니다.

행복한고니   07-03-27 22:54   아... IE에서는 증명하셨다 그랬죠? var o = Object; delete Object; alert({}); alert(new o); alert( ({}).constructor === (new o).constructor); 이것도 한번 테스트 해주세요. 사라진 Object 객체가 어떻게 생성자로서의 역할을 할 수 있을까요? ^^ 과연 이게 Object 객체가 사라진 것일까요, 아니면 명시적인 선언만 안되게 해놓은 IE의 특징일까요? 판단은 다른 분들이 알아서 하시겠죠. :) 필요하시면 블로그에 퍼가도 좋습니다. ㅋㅋ 수고하셨습니다. (__) 아마도 또 답글이 달릴 것 같지만... 어쨌거나요 ㅎㅎ 아... IE에서는 증명하셨다 그랬죠? var o = Object; delete Object; alert({}); alert(new o); alert( ({}).constructor === (new o).constructor); 이것도 한번 테스트 해주세요. 사라진 Object 객체가 어떻게 생성자로서의 역할을 할 수 있을까요? ^^ 과연 이게 Object 객체가 사라진 것일까요, 아니면 명시적인 선언만 안되게 해놓은 IE의 특징일까요? 판단은 다른 분들이 알아서 하시겠죠. :) 필요하시면 블로그에 퍼가도 좋습니다. ㅋㅋ 수고하셨습니다. (__) 아마도 또 답글이 달릴 것 같지만... 어쨌거나요 ㅎㅎ

숨어지내리   07-03-27 23:18   아직도 객체,상속,생성자를 이해하고 있지 않은듯 합니다. ^^ㅋㅋㅋ constructor 로 비교하시지 말라 그래도..ㅋㅋ 잘 생각해보세요.. ^^ㅋㅋㅋㅋ 삭제못하게 만드려고 var 를 붙였네요.ㅋㅋ http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Operators:Special_Operators:delete_Operator x=42 var y= 43 myobj=new Number() myobj.h=4      // create property h delete x      // returns true (can delete if declared implicitly) delete y      // returns false (cannot delete if declared with var) delete Math.PI // returns false (cannot delete predefined properties) delete myobj.h // returns true (can delete user-defined properties) delete myobj  // returns true (can delete objects) 지금 퀴즈하자는 겁니까? ㅋㅋㅋ 재미없습니다. 사용방법도 모르고 왜그러냐니..ㅡㅡ; 한심합니다.. 언능 주무세요.. 오늘 회사도 이것때문에 안나갔습니다. ^^ㅋㅋㅋ for(var i = 0 ; i < 100 ; ++i) { 행복한고니 = "수고하셨습니다."; } 수고하세요.~~~~ 아직도 객체,상속,생성자를 이해하고 있지 않은듯 합니다. ^^ㅋㅋㅋ constructor 로 비교하시지 말라 그래도..ㅋㅋ 잘 생각해보세요.. ^^ㅋㅋㅋㅋ 삭제못하게 만드려고 var 를 붙였네요.ㅋㅋ http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Operators:Special_Operators:delete_Operator x=42 var y= 43 myobj=new Number() myobj.h=4 // create property h delete x // returns true (can delete if declared implicitly) delete y // returns false (cannot delete if declared with var) delete Math.PI // returns false (cannot delete predefined properties) delete myobj.h // returns true (can delete user-defined properties) delete myobj // returns true (can delete objects) 지금 퀴즈하자는 겁니까? ㅋㅋㅋ 재미없습니다. 사용방법도 모르고 왜그러냐니..ㅡㅡ; 한심합니다.. 언능 주무세요.. 오늘 회사도 이것때문에 안나갔습니다. ^^ㅋㅋㅋ for(var i = 0 ; i < 100 ; ++i) { 행복한고니 = "수고하셨습니다."; } 수고하세요.~~~~

행복한고니   07-03-27 23:22   ㅋㅋ 그렇게 나올 줄 알았죠. 이번엔 또 MDC 문서로군요! var 도 빼고 한번 해보세요. ^^ 물론, 해보시고 저한테 "한심하다"고 하신거겠죠? 아... 다음 코드도 한번~ ^^ var o1 = new Object; delete Object; var o2 = {}; alert(o1.constructor == o2.constructor); alert(o2 instanceof o1.constructor); Object는 삭제되었을텐데, 두 객체의 constructor가 같다고도 하고, o2 는 o1의 생성자의 인스턴스가 맞다는데 이걸 어떻게 해석해야 할까요? ___________________________________________ 이것때문에 잠도 못자고 회사도 안나가고 바쁘시네요. :) 전 잠도 잘자고 일도 많이했는데요. 아... 스터디도 진행했었군요. ^^ ㅋㅋ 그렇게 나올 줄 알았죠. 이번엔 또 MDC 문서로군요! var 도 빼고 한번 해보세요. ^^ 물론, 해보시고 저한테 "한심하다"고 하신거겠죠? 아... 다음 코드도 한번~ ^^ var o1 = new Object; delete Object; var o2 = {}; alert(o1.constructor == o2.constructor); alert(o2 instanceof o1.constructor); Object는 삭제되었을텐데, 두 객체의 constructor가 같다고도 하고, o2 는 o1의 생성자의 인스턴스가 맞다는데 이걸 어떻게 해석해야 할까요? ___________________________________________ 이것때문에 잠도 못자고 회사도 안나가고 바쁘시네요. :) 전 잠도 잘자고 일도 많이했는데요. 아... 스터디도 진행했었군요. ^^

숨어지내리   07-03-27 23:40   ㅋㅋㅋ 재미있습니다. ^^ 지지 않으려고.. 지푸라기 잡는거..ㅋㅋㅋ var o1 = new Object; // 상속처리 delete Object;  // 삭제 var o2 = {}; alert(o1.constructor === o2.constructor); Object 를 delete 하기전에 이미 상속을 받았으니 constructor 라는 값을 가지고 있는거지요..ㅋㅋㅋㅋ 상속에 대해 진정 모릅니까? ㅋㅋㅋ 헛발 디디라고 하나이까??ㅋㅋㅋ 미치겠네요.. 정말..ㅋㅋㅋ 이젠 한계에 도달합니다. delete Object;  // 삭제 var o1 = new Object; // 상속처리 -> 에러..객체없음 var o2 = {}; alert(o1.constructor === o2.constructor); ie 에서 이게 동작을 하지 않는데...ㅋㅋㅋ 재미있네요..ㅋㅋ 무슨 의미가 있나요? ㅋㅋㅋㅋㅋ ㅋㅋㅋ 재미있습니다. ^^ 지지 않으려고.. 지푸라기 잡는거..ㅋㅋㅋ var o1 = new Object; // 상속처리 delete Object; // 삭제 var o2 = {}; alert(o1.constructor === o2.constructor); Object 를 delete 하기전에 이미 상속을 받았으니 constructor 라는 값을 가지고 있는거지요..ㅋㅋㅋㅋ 상속에 대해 진정 모릅니까? ㅋㅋㅋ 헛발 디디라고 하나이까??ㅋㅋㅋ 미치겠네요.. 정말..ㅋㅋㅋ 이젠 한계에 도달합니다. delete Object; // 삭제 var o1 = new Object; // 상속처리 -> 에러..객체없음 var o2 = {}; alert(o1.constructor === o2.constructor); ie 에서 이게 동작을 하지 않는데...ㅋㅋㅋ 재미있네요..ㅋㅋ 무슨 의미가 있나요? ㅋㅋㅋㅋㅋ

행복한고니   07-03-28 00:00   역시.. 이해할 거라곤 기대하지도 않았습니다. 우선 또 오해가 있기전에 정리부터 하죠. 객관식으로 드리겠습니다. Object를 삭제했는데, new Object가 안되고 {}가 되는 것은 fact입니다. 이것이 의미하는 바가 무엇입니까? 1. new Object는 Object객체를 사용하지만, {}는 그렇지 않다. 2. new Object는 안되고 {}는 되니까 그것만으로도 다르다는게 증명된다. 3. 기타 의견 저는 희한하게도 Object 객체를 삭제했는데도 {}가 여전히 Object의 인스턴스라는 점을 말하고 있을 뿐입니다. 그래서 희한하다고 한거죠. Object가 constructor에 있다고 칩시다. 그러면 어떻게 {}는 다시 Object의 인스턴스가 될 수 있었을까요? Object는 정말로 삭제된 것일까요, 남아있는데도 삭제된 것으로 취급하는 IE가 이상한 것일까요? Object가 삭제되었는데 어째서 {}는 Object의 인스턴스가 될 수 있느냐를 묻는거였는데요. instanceof 는 왜 쏙 빼먹고 말씀안하시나요? ^^ 유리한 것만 하지 마시고, 다른 것도 말씀하셔야죠. 제 의도는 있는 것을 없다하는 IE를 얘기하고 있을 뿐입니다. 저는 님의 의도대로 IE가 동작해준게 과연 정상적인지, 버그 혹은 오동작인지에 대해서 의문을 제가하는 겁니다. 역시.. 이해할 거라곤 기대하지도 않았습니다. 우선 또 오해가 있기전에 정리부터 하죠. 객관식으로 드리겠습니다. Object를 삭제했는데, new Object가 안되고 {}가 되는 것은 fact입니다. 이것이 의미하는 바가 무엇입니까? 1. new Object는 Object객체를 사용하지만, {}는 그렇지 않다. 2. new Object는 안되고 {}는 되니까 그것만으로도 다르다는게 증명된다. 3. 기타 의견 저는 희한하게도 Object 객체를 삭제했는데도 {}가 여전히 Object의 인스턴스라는 점을 말하고 있을 뿐입니다. 그래서 희한하다고 한거죠. Object가 constructor에 있다고 칩시다. 그러면 어떻게 {}는 다시 Object의 인스턴스가 될 수 있었을까요? Object는 정말로 삭제된 것일까요, 남아있는데도 삭제된 것으로 취급하는 IE가 이상한 것일까요? Object가 삭제되었는데 어째서 {}는 Object의 인스턴스가 될 수 있느냐를 묻는거였는데요. instanceof 는 왜 쏙 빼먹고 말씀안하시나요? ^^ 유리한 것만 하지 마시고, 다른 것도 말씀하셔야죠. 제 의도는 있는 것을 없다하는 IE를 얘기하고 있을 뿐입니다. 저는 님의 의도대로 IE가 동작해준게 과연 정상적인지, 버그 혹은 오동작인지에 대해서 의문을 제가하는 겁니다.

숨어지내리   07-03-28 00:31   ㅋㅋㅋㅋㅋ 이젠 버그이군요.. 주관적인 생각을 주입시켜주셔서 감사드립니다. 캬캬캬..^^; ㅋㅋㅋㅋㅋ 이젠 버그이군요.. 주관적인 생각을 주입시켜주셔서 감사드립니다. 캬캬캬..^^;

행복한고니   07-03-28 00:37   아... 님에게 JScript를 지원하는 IE는 JavaScript의 완벽한 표본이군요. 그럼요. IE의 CSS, 렌더링, 메모리 릭 등을 포함한 버그들도 다 IE가 틀린게 아니죠. IE는 완벽하니 다른 브라우저가 잘못된 것이죠. 그말이 옳습니다 ㅎㅎ 그럼 그냥 그렇게 생각하세요. 개발자로서 아주 훌륭한 마인드입니다. 이해할 수 없는 현상에 대해 문제제기를 하는게 "지극히 주관적인 현상"이었군요. 아직도 intanceof 가 왜 그렇게 나오는가에 대해서는 대답도 못하고 자기 말이 옳다는 것을 증명할 수 있는 사실 하나만 붙잡고(그나마도 JavaScript 호환언어에서) 계시네요. ^^ 다른 건 다 제쳐두고, "이것봐라. 그러니까 내 말이 옳다"만 반복하고 있으시네요. ㅎㅎ 그만 주무세요. 까딱하면 오늘도 못 주무실 수 있겠어요. :) 아... 님에게 JScript를 지원하는 IE는 JavaScript의 완벽한 표본이군요. 그럼요. IE의 CSS, 렌더링, 메모리 릭 등을 포함한 버그들도 다 IE가 틀린게 아니죠. IE는 완벽하니 다른 브라우저가 잘못된 것이죠. 그말이 옳습니다 ㅎㅎ 그럼 그냥 그렇게 생각하세요. 개발자로서 아주 훌륭한 마인드입니다. 이해할 수 없는 현상에 대해 문제제기를 하는게 "지극히 주관적인 현상"이었군요. 아직도 intanceof 가 왜 그렇게 나오는가에 대해서는 대답도 못하고 자기 말이 옳다는 것을 증명할 수 있는 사실 하나만 붙잡고(그나마도 JavaScript 호환언어에서) 계시네요. ^^ 다른 건 다 제쳐두고, "이것봐라. 그러니까 내 말이 옳다"만 반복하고 있으시네요. ㅎㅎ 그만 주무세요. 까딱하면 오늘도 못 주무실 수 있겠어요. :)

낭망백수   07-03-27 22:59   이 논쟁을 이해하면 경지에 오르는 건가요? ㅎㅎ 대단들 하십니다. ^^ 꾸벅~! 이 논쟁을 이해하면 경지에 오르는 건가요? ㅎㅎ 대단들 하십니다. ^^ 꾸벅~!

무소레즈   07-03-27 23:15   meat1 이나 meat2 나 모두 price 함수 객체타입의 instance 입니다. instance 개체를 생성하면 constructor 로써 price의 초기환경설정이 시작합니다. constructor 라는 것이 원래 그런 목적으로 만들어진것이니까요. 그렇게 constructor 는 개체의 초기조건과 초기 실행환경을 만들어 줍니다. 주어진 조건이 다르다면  생성된 instance 개체의 실행 행위가 달라집니다. 물론 이렇게 실행환경이 달라지더라도  instance 라는 것은 같습니다. instance 는 어떤 객체타입의 instance 를 가졌는가를 알려줄 뿐이지만, instance 객체라는 것은 실체화된 독립적인 개체로서 주어진 객체타입에서 설계된 구조의 제어대로 실행을 하는 실체입니다. 예문에서 보면, instance 객체 생성시 초기 생성자 함수가 비록 price 였지만 price 내부에 들어가면, 주어진 조건에의해 다른 constructor 의 제어를 받습니다. 개체의 새로운 실행 환경이 주어지게 되는것이지요. 그 예문에서 constructor 재설정은 의미는 어떤 객체타입의 실행환경을 가졌는가를 확인하기위한 일종의 안내일뿐입니다. 생성된 instance 개체가 어떤 환경하에서 실행되는지 확인하기 위한것이라는 것이지요. 서로 다른 생성자에의해 다른 환경조건이 주어졌다면 instance 개체는 다른 실행을 하게 된다는 것이지요. instance 객체를 생성시  초기 생성자 함수 객체타입은 위의 price 함수에서 보여진대로, 조건에따라 내부에서 다른 constructor 를 통하여 새로운 환경을 가지게 됩니다. 처음의 price  생성자가 소멸아닌 소멸이 되어 버리는 것이지요. 이 얘기 역시, 존재는 하지만 실제 실행주체를 위한 생성자가 아니니 소멸이라고 표현한것 뿐입니다. ---------------------------- 반복되는 얘기일수도 있지만 행복한 고니님의 글에 답변성 글을 올립니다. 글재주가 부족해서 무슨 말을 어떻게 썼는지 흠... 아뭏든 제가 아는 바는 아래와 같습니다. ---------------------------- -->> price 는 meat1의 생성자이고 meat1은 price의 인스턴스입니다 <<-- meat1 은 price 함수 객체타입의 인스터스를 가지고 있다... 라고 해야하지 않을까 합니다. 서로 이해하면 되니까 그건 그렇다고 하지요. price 함수 조건별 제어에의해 meat1 의 생성자가 price 가 되지 않도록 할 수도 있습니다. 생성자란것이 초기 실행 환경설정의 주체이기때문에 constructor 의 재정의가 아닌 조건별 constructor 의 선택에의해 실행환경을 바꿀수 있습니다. -->> 이 사실은 설령 meat1의 constructor가 재정의 된 것처럼 보이더라도 변하지 않습니다. 재정의 된 것처럼 보일 뿐이죠. <<-- 재정의된것처럼 보이는것도 맞습니다.. 그렇게 요청시에 안내만 해준것 뿐입니다. (개체.constructor) 의 확인 목적은 instance 개체가 생성자(객체타입)의 어떤 초기 실행 환경을 가졌는지를 알기 위함이라고 알고 있습니다. <<-- function price (){} meat = new price;   객체타입 price 는 함수 객체타입인 생성자 입니다. 실행환경과 실행구조를 정의합니다. price 함수객체 내부에는 조건별 생성자와 그에따른 실제 행위를 할 method 의 구조를 정의할수도 있습니다.     인스턴스 instance 는 어떤 객체타입인가를 얘기합니다. meat 의 instance 는  "function price (){}" 입니다. 즉, meta 는 함수객체 price 타입의 instance 를 가졌다고 말할 수 있습니다. 또한, new 를 통해 instance 개체를 생성하면 새로 생성된 instance 개체의 instance는 자동으로 함수객체 Object 타입을 갖게 됩니다.     인스턴스 개체 meat 는 instance 개체입니다. instance 가 아닌 해당 객체타입의 instance 를 가진 개체입니다. instance 개체는  해당 생성자에서 주어진 환경설정과 실행명령에의해 직접 실행을 하게 되는 실행주체입니다. meat1 이나 meat2 나 모두 price 함수 객체타입의 instance 입니다. instance 개체를 생성하면 constructor 로써 price의 초기환경설정이 시작합니다. constructor 라는 것이 원래 그런 목적으로 만들어진것이니까요. 그렇게 constructor 는 개체의 초기조건과 초기 실행환경을 만들어 줍니다. 주어진 조건이 다르다면 생성된 instance 개체의 실행 행위가 달라집니다. 물론 이렇게 실행환경이 달라지더라도 instance 라는 것은 같습니다. instance 는 어떤 객체타입의 instance 를 가졌는가를 알려줄 뿐이지만, instance 객체라는 것은 실체화된 독립적인 개체로서 주어진 객체타입에서 설계된 구조의 제어대로 실행을 하는 실체입니다. 예문에서 보면, instance 객체 생성시 초기 생성자 함수가 비록 price 였지만 price 내부에 들어가면, 주어진 조건에의해 다른 constructor 의 제어를 받습니다. 개체의 새로운 실행 환경이 주어지게 되는것이지요. 그 예문에서 constructor 재설정은 의미는 어떤 객체타입의 실행환경을 가졌는가를 확인하기위한 일종의 안내일뿐입니다. 생성된 instance 개체가 어떤 환경하에서 실행되는지 확인하기 위한것이라는 것이지요. 서로 다른 생성자에의해 다른 환경조건이 주어졌다면 instance 개체는 다른 실행을 하게 된다는 것이지요. instance 객체를 생성시 초기 생성자 함수 객체타입은 위의 price 함수에서 보여진대로, 조건에따라 내부에서 다른 constructor 를 통하여 새로운 환경을 가지게 됩니다. 처음의 price 생성자가 소멸아닌 소멸이 되어 버리는 것이지요. 이 얘기 역시, 존재는 하지만 실제 실행주체를 위한 생성자가 아니니 소멸이라고 표현한것 뿐입니다. ---------------------------- 반복되는 얘기일수도 있지만 행복한 고니님의 글에 답변성 글을 올립니다. 글재주가 부족해서 무슨 말을 어떻게 썼는지 흠... 아뭏든 제가 아는 바는 아래와 같습니다. ---------------------------- -->> price 는 meat1의 생성자이고 meat1은 price의 인스턴스입니다 <<-- meat1 은 price 함수 객체타입의 인스터스를 가지고 있다... 라고 해야하지 않을까 합니다. 서로 이해하면 되니까 그건 그렇다고 하지요. price 함수 조건별 제어에의해 meat1 의 생성자가 price 가 되지 않도록 할 수도 있습니다. 생성자란것이 초기 실행 환경설정의 주체이기때문에 constructor 의 재정의가 아닌 조건별 constructor 의 선택에의해 실행환경을 바꿀수 있습니다. -->> 이 사실은 설령 meat1의 constructor가 재정의 된 것처럼 보이더라도 변하지 않습니다. 재정의 된 것처럼 보일 뿐이죠. <<-- 재정의된것처럼 보이는것도 맞습니다.. 그렇게 요청시에 안내만 해준것 뿐입니다. (개체.constructor) 의 확인 목적은 instance 개체가 생성자(객체타입)의 어떤 초기 실행 환경을 가졌는지를 알기 위함이라고 알고 있습니다. <<-- function price (){} meat = new price; 객체타입 price 는 함수 객체타입인 생성자 입니다. 실행환경과 실행구조를 정의합니다. price 함수객체 내부에는 조건별 생성자와 그에따른 실제 행위를 할 method 의 구조를 정의할수도 있습니다. 인스턴스 instance 는 어떤 객체타입인가를 얘기합니다. meat 의 instance 는 "function price (){}" 입니다. 즉, meta 는 함수객체 price 타입의 instance 를 가졌다고 말할 수 있습니다. 또한, new 를 통해 instance 개체를 생성하면 새로 생성된 instance 개체의 instance는 자동으로 함수객체 Object 타입을 갖게 됩니다. 인스턴스 개체 meat 는 instance 개체입니다. instance 가 아닌 해당 객체타입의 instance 를 가진 개체입니다. instance 개체는 해당 생성자에서 주어진 환경설정과 실행명령에의해 직접 실행을 하게 되는 실행주체입니다.

행복한고니   07-03-27 23:29   여태껏 제가 했던 주장을 instanceof 연산자를 사용해서 한다해도 다 똑같은 결과가 나옵니다. 유연함으로 인해 재설정이 가능한 것과 실제 성질이 그러한 것을 혼동하시는 것 같습니다. 최초에 만들어진 meat1은 분명 price라는 contructor를 가지고 있었으나 price 내부에서 유연함을 이용해 재설정 해버린 것입니다. 제가 요구하는게 재설정이 가능한지를 묻는 것이었던 것은 아닌걸 아실텐데요. constructor가 재설정이 가능하기 때문에 신뢰성이 없다면, instanceof 연산자를 가지고 바꾸어 생각하셔도 좋습니다. 언어의 유연함을 이용해 constructor를 강제로 바꾸고서 "constructor속성이 달라졌으니 생성자가 다르다"라고 말할 수 있을지 의문입니다. 아... 그리고.. constructor가 바뀐다고 님의 표현대로인 "실행환경" 혹은 제 표현인 "타입/성질"이 바뀌는 것은 아닙니다. function class1(){ this.aa = "b"; } function class2(){ this.aa = "c"; } var a = new class1(); alert(a.constructor); alert(a.aa); a.constructor = class2; alert(a.constructor); alert(a.aa); 이렇게 하면 답변이 될까요? 여태껏 제가 했던 주장을 instanceof 연산자를 사용해서 한다해도 다 똑같은 결과가 나옵니다. 유연함으로 인해 재설정이 가능한 것과 실제 성질이 그러한 것을 혼동하시는 것 같습니다. 최초에 만들어진 meat1은 분명 price라는 contructor를 가지고 있었으나 price 내부에서 유연함을 이용해 재설정 해버린 것입니다. 제가 요구하는게 재설정이 가능한지를 묻는 것이었던 것은 아닌걸 아실텐데요. constructor가 재설정이 가능하기 때문에 신뢰성이 없다면, instanceof 연산자를 가지고 바꾸어 생각하셔도 좋습니다. 언어의 유연함을 이용해 constructor를 강제로 바꾸고서 "constructor속성이 달라졌으니 생성자가 다르다"라고 말할 수 있을지 의문입니다. 아... 그리고.. constructor가 바뀐다고 님의 표현대로인 "실행환경" 혹은 제 표현인 "타입/성질"이 바뀌는 것은 아닙니다. function class1(){ this.aa = "b"; } function class2(){ this.aa = "c"; } var a = new class1(); alert(a.constructor); alert(a.aa); a.constructor = class2; alert(a.constructor); alert(a.aa); 이렇게 하면 답변이 될까요?

무소레즈   07-03-28 10:43   설명이 필요하여 보여드린 소스에 달랑 (객체.constructor) 만 구현되어 있어서 constructor 에대한 언급시 constructor 함수객체와 혼동이 있으신것 같군요. 생성자가 다르게 구현되는 좀 더 구체적인 예제 소스를 작성해 보지요. 설명이 필요하여 보여드린 소스에 달랑 (객체.constructor) 만 구현되어 있어서 constructor 에대한 언급시 constructor 함수객체와 혼동이 있으신것 같군요. 생성자가 다르게 구현되는 좀 더 구체적인 예제 소스를 작성해 보지요.

무소레즈   07-03-27 23:40   글의 의도된 의미를 거듭 얘기했어도 의미전달이 제대로 되어지고 있지 않군요. 앨리스가 된 기분... 가능하다면 내가 작성한 글을 모두 삭제해 버리고 싶네요.. 운영자님이 보시면.. 삭제좀 해줬으면 좋겠어요. 글의 의도된 의미를 거듭 얘기했어도 의미전달이 제대로 되어지고 있지 않군요. 앨리스가 된 기분... 가능하다면 내가 작성한 글을 모두 삭제해 버리고 싶네요.. 운영자님이 보시면.. 삭제좀 해줬으면 좋겠어요.

행복한고니   07-03-27 23:52   인스턴스 부분에서 이해를 잘못하신 것 같네요. 어떤 클래스가 있을 때, 그것은 그냥 구조로만 존재합니다(물론, 자바스크립트에서는 함수 개체로 존재하지만). 그 클래스를 실제로 구현했을 때를 인스턴스라고 합니다. http://www.terms.co.kr/instance.htm 따라서 meat1의 클래스는 price이고, price의 인스턴스가 meat1 입니다. 이 부분을 오해하신 것 같네요. 님께서 인스턴스 객체라고 말한 것이 제 용어에서 인스턴스이고, 인스턴스라는 개념이 클래스라는 뜻으로 사용된 것 같네요. 자바스크립트에서는 생성자가 곧 객체 타입도 됩니다. 이 부분을 간과하신 것 같네요. 함수 내부에서만 구조가 정의된다고 생각하시겠지만... price.prototype.someProp = '111'; price.prototype.someFunc = function(){}; 과 같이도 정의할 수 있습니다. 따라서, price와 객체의 "실행환경"이라는 것과 별개로 생각하시는 것은 잘못 이해하고 계신겁니다. 대체 인스턴스와 인스턴스 객체가 어떻게 다른지 용어가 다른 문제인데요. 인스턴스 객체를 다른 의미로 사용하는 건 진짜로 첨봤습니다. -_-;; 인스턴스 부분에서 이해를 잘못하신 것 같네요. 어떤 클래스가 있을 때, 그것은 그냥 구조로만 존재합니다(물론, 자바스크립트에서는 함수 개체로 존재하지만). 그 클래스를 실제로 구현했을 때를 인스턴스라고 합니다. http://www.terms.co.kr/instance.htm 따라서 meat1의 클래스는 price이고, price의 인스턴스가 meat1 입니다. 이 부분을 오해하신 것 같네요. 님께서 인스턴스 객체라고 말한 것이 제 용어에서 인스턴스이고, 인스턴스라는 개념이 클래스라는 뜻으로 사용된 것 같네요. 자바스크립트에서는 생성자가 곧 객체 타입도 됩니다. 이 부분을 간과하신 것 같네요. 함수 내부에서만 구조가 정의된다고 생각하시겠지만... price.prototype.someProp = '111'; price.prototype.someFunc = function(){}; 과 같이도 정의할 수 있습니다. 따라서, price와 객체의 "실행환경"이라는 것과 별개로 생각하시는 것은 잘못 이해하고 계신겁니다. 대체 인스턴스와 인스턴스 객체가 어떻게 다른지 용어가 다른 문제인데요. 인스턴스 객체를 다른 의미로 사용하는 건 진짜로 첨봤습니다. -_-;;

무소레즈   07-03-28 00:19   제가 올린 글을 제대로 읽어본 후 표현한 글인지 의심이 가는 답변이로군요. 정말 엉뚱한 답변의 연속입니다. 제가 올린 글을 제대로 읽어본 후 표현한 글인지 의심이 가는 답변이로군요. 정말 엉뚱한 답변의 연속입니다.

행복한고니   07-03-28 00:26   에효... 그냥 그렇다고 해두죠. 무슨 말인지 이해해보려고 해도 이것도 아닌가보군요. 뭔가 다른 소리를 각자 하고 있는 것 같으니 그만두죠 뭐. 에효... 그냥 그렇다고 해두죠. 무슨 말인지 이해해보려고 해도 이것도 아닌가보군요. 뭔가 다른 소리를 각자 하고 있는 것 같으니 그만두죠 뭐.

무소레즈   07-03-28 01:10   행복한 고니님, 숨어지내리님 수고들 하셨습니다. 다음에 이런 공간이 다시 주어지면 보다 덜 소모적인 대화가 진행되었으면 하는 아쉬움이 있습니다만. 그래도 나름 즐거운 시간이었습니다.  ^^ ------------------ 올린 글을 다시 보니... 인스턴스 부분 설명이 잘못되었네요.     meat 의 instance 는  "function price (){}" 입니다.  는 잘못된 글입니다.     [인스턴스]     instance 는 어떤 객체타입인가를 얘기합니다.     meat 의 constructor 는 "function price (){}" 입니다.     ( meat instanceof price ) 는 true 입니다.     즉, meat는 함수객체 price 타입의 instance 를 가졌다고 말할 수 있습니다.     또한, new 를 통해 instance 개체를 생성하면     새로 생성된 instance 개체의 instance는 자동으로 함수객체 Object 타입을 갖게 됩니다. 로 정정합니다. 행복한 고니님, 숨어지내리님 수고들 하셨습니다. 다음에 이런 공간이 다시 주어지면 보다 덜 소모적인 대화가 진행되었으면 하는 아쉬움이 있습니다만. 그래도 나름 즐거운 시간이었습니다. ^^ ------------------ 올린 글을 다시 보니... 인스턴스 부분 설명이 잘못되었네요. meat 의 instance 는 "function price (){}" 입니다. 는 잘못된 글입니다. [인스턴스] instance 는 어떤 객체타입인가를 얘기합니다. meat 의 constructor 는 "function price (){}" 입니다. ( meat instanceof price ) 는 true 입니다. 즉, meat는 함수객체 price 타입의 instance 를 가졌다고 말할 수 있습니다. 또한, new 를 통해 instance 개체를 생성하면 새로 생성된 instance 개체의 instance는 자동으로 함수객체 Object 타입을 갖게 됩니다. 로 정정합니다.

무소레즈   07-03-28 11:16   function arirang (flag){     if(flag == 1) {         a =new Function;         a.constructor=(new Object).constructor;         a.run=new Function("return ('arirang - 꽃');");         return a;     }     else {         b=new Function;         b.constructor=(new Date).constructor;         b.run=new Function("return ('arirang - 요일');");         b.getDayKr=function () {             return  ['일','월','화','수','목','금','토'][(new Date).getDay()];         }         return b;     } } flower= new arirang(1); week = new arirang(0); //----------------------------- function echo (str) {     if(echo.arguments.length==0) str='';     if( (s_arr=str.split('::')).length>1 ) str=s_arr[0].bold()+' :: ' + s_arr[1];     document.write(str+'<br>'); } echo ('flower.run() :: ' + flower.run() ); echo ('week.run()  :: ' + week.run() ); echo ('week.getDayKr() :: ' + week.getDayKr().concat('요일') ); echo () echo ('flower instanceof arirang :: ' +  (flower instanceof arirang ) ) echo ('week instanceof arirang :: ' +  (week instanceof arirang ) ); echo () echo ('(flower.constructor == week.constructor) :: ' +  (flower.constructor == week.constructor) ) echo ('flower.constructor :: ' +  (flower.constructor) ) echo ('week.constructor :: ' +  (week.constructor) ) echo () echo ('week.constructor === Date.prototype.constructor :: ' + (week.constructor === Date.prototype.constructor ) ); function arirang (flag){ if(flag == 1) { a =new Function; a.constructor=(new Object).constructor; a.run=new Function("return ('arirang - 꽃');"); return a; } else { b=new Function; b.constructor=(new Date).constructor; b.run=new Function("return ('arirang - 요일');"); b.getDayKr=function () { return ['일','월','화','수','목','금','토'][(new Date).getDay()]; } return b; } } flower= new arirang(1); week = new arirang(0); //----------------------------- function echo (str) { if(echo.arguments.length==0) str=''; if( (s_arr=str.split('::')).length>1 ) str=s_arr[0].bold()+' :: ' + s_arr[1]; document.write(str+'<br>'); } echo ('flower.run() :: ' + flower.run() ); echo ('week.run() :: ' + week.run() ); echo ('week.getDayKr() :: ' + week.getDayKr().concat('요일') ); echo () echo ('flower instanceof arirang :: ' + (flower instanceof arirang ) ) echo ('week instanceof arirang :: ' + (week instanceof arirang ) ); echo () echo ('(flower.constructor == week.constructor) :: ' + (flower.constructor == week.constructor) ) echo ('flower.constructor :: ' + (flower.constructor) ) echo ('week.constructor :: ' + (week.constructor) ) echo () echo ('week.constructor === Date.prototype.constructor :: ' + (week.constructor === Date.prototype.constructor ) );

행복한고니   07-03-28 11:29   아무리봐도 제가 이해하기에는 했던 말을 반복할 수 밖에 없습니다. 어떻게 constructor하고 instance하고 따로 생각할 수 있는지 이해가 안됩니다. flower가 arirang의 인스턴스라고 이미 instanceof 에서 나왔는데 재정의된 constructor를 비교해봐야 무슨 소용이 있는 줄 모르겠군요. 재정의된 상태에서 constructor를 비교하는 것은 정말 단순한 객체의 비교밖에 안됩니다. var b = new Function; b.constructor = Date; // (new Date).constructor는 Date var d = new Date; Date.prototype.aa = "aa"; alert(b.aa); alert(d.aa); b의 constructor를 강제로 바꿔봤자 b 라는 객체에 영향을 끼치는 것은 최초의 생성자이지, 그 뒤에 constructor라는 속성을 재설정해봐야 소용없다는 말입니다. Date는 b 객체에 대해 아무런 영향도 끼치지 못합니다. 도대체 코드가 의미하는 바를 알 수가 없군요. 제가 드리는 이 명제를 동의하지 못한다면 자바스크립트의 특성을 잘못이해하고 계시는 것이니, 그냥 이쯤에서 그만두는게 좋을 것 같습니다. 자꾸 반복만 할 것 같습니다. "자바스크립트에서는 생성자가 곧 객체타입입니다." 아무리봐도 제가 이해하기에는 했던 말을 반복할 수 밖에 없습니다. 어떻게 constructor하고 instance하고 따로 생각할 수 있는지 이해가 안됩니다. flower가 arirang의 인스턴스라고 이미 instanceof 에서 나왔는데 재정의된 constructor를 비교해봐야 무슨 소용이 있는 줄 모르겠군요. 재정의된 상태에서 constructor를 비교하는 것은 정말 단순한 객체의 비교밖에 안됩니다. var b = new Function; b.constructor = Date; // (new Date).constructor는 Date var d = new Date; Date.prototype.aa = "aa"; alert(b.aa); alert(d.aa); b의 constructor를 강제로 바꿔봤자 b 라는 객체에 영향을 끼치는 것은 최초의 생성자이지, 그 뒤에 constructor라는 속성을 재설정해봐야 소용없다는 말입니다. Date는 b 객체에 대해 아무런 영향도 끼치지 못합니다. 도대체 코드가 의미하는 바를 알 수가 없군요. 제가 드리는 이 명제를 동의하지 못한다면 자바스크립트의 특성을 잘못이해하고 계시는 것이니, 그냥 이쯤에서 그만두는게 좋을 것 같습니다. 자꾸 반복만 할 것 같습니다. "자바스크립트에서는 생성자가 곧 객체타입입니다."

무소레즈   07-03-28 11:32   flower가 arirang의 인스턴스라고  나온 부분과 소스를  다시 잘 보시기 바랍니다. flower가 arirang의 인스턴스라고 나온 부분과 소스를 다시 잘 보시기 바랍니다.

무소레즈   07-03-28 11:39   상대가 무슨 얘길 하는지 확인하고 답변을 다는것이 좋지 않을까요? 소스를 구현해주고, 보기 편하라고 실행결과까지 구현해주었는데도 ... 그 마저 대충 보고 얘길하면 대화가 되겠습니까? 또한 생성자란 함수 객체여야만 생성이 되는 것이고, 객체타입을 갖는 것이 당연한것을 대단한 것처럼 동의를 구하려 하시는군요. 상대가 무슨 얘길 하는지 확인하고 답변을 다는것이 좋지 않을까요? 소스를 구현해주고, 보기 편하라고 실행결과까지 구현해주었는데도 ... 그 마저 대충 보고 얘길하면 대화가 되겠습니까? 또한 생성자란 함수 객체여야만 생성이 되는 것이고, 객체타입을 갖는 것이 당연한것을 대단한 것처럼 동의를 구하려 하시는군요.

행복한고니   07-03-28 11:40   거기까지는 이해했는데, 왜 재설정된 contructor를 비교하는건지 의도파악이 안되서 그런겁니다. 재설정되버린 것은 객체에 아무런 의미도 없는데 왜 비교를 하신건가요? 거기까지는 이해했는데, 왜 재설정된 contructor를 비교하는건지 의도파악이 안되서 그런겁니다. 재설정되버린 것은 객체에 아무런 의미도 없는데 왜 비교를 하신건가요?

무소레즈   07-03-28 11:47   밥 지어 주니까...밥까지 먹여 달라는 격이로군요.. 행복한 고니님이 반론 펴신 내용의 대한 답으로 실행문을 예로 보여준것입니다. 다시 잘 보시고...  무슨 의미인지 나름 판단해보시기 바랍니다. 뭐 어찌되었건 대화이니 대화 그 자체로 지나쳐 버려도 될 일입니다. 오늘따라 날이 찌뿌둥 하군요. 밥 지어 주니까...밥까지 먹여 달라는 격이로군요.. 행복한 고니님이 반론 펴신 내용의 대한 답으로 실행문을 예로 보여준것입니다. 다시 잘 보시고... 무슨 의미인지 나름 판단해보시기 바랍니다. 뭐 어찌되었건 대화이니 대화 그 자체로 지나쳐 버려도 될 일입니다. 오늘따라 날이 찌뿌둥 하군요.

행복한고니   07-03-28 12:06   제 의도를 정리해드리죠. "인스턴스를 만들고 난 이후에 constructor를 재설정해도 그것은 이미 생성자로서의 의미를 가지지 못하며, 재설정되는 것은 단순히 자바스크립트의 유연성에서 비롯되는 것일 뿐이다. 따라서, "강제로 재설정한" constructor를 비교하는 것은 아무런 의미가 없다." 입니다. 유연함으로 인해 constructor 속성이 아무 값이라도 상관없이 재설정 할 수 있다는 것은 meat1.constructor = 1 이라는 예제를 통해서 이미 충분히 입증되었다고 생각합니다. 함수객체가 아닌 것도 constructor 속성에 설정될 수 있으니까요. "강제 재설정" 자체가 의미가 없다는 겁니다. "생성자가 곧 객체타입"이라 했습니다. 그렇다면, constructor를 재설정해서 객체타입이 변하느냐... 그게 아니라는 겁니다. 그래서 그렇게 바꾼 constructor는 아무런 의미도 없다는 것을 바로 위에서 말씀드렸습니다. 오히려 constructor를 바꿔도 최초의 생성자가 여전히 해당 인스턴스에 영향을 미치고 있음을 알 수 있습니다. 이제 다시 물어보겠습니다. 왜 강제로 재설정한 constructor를 비교하신건가요? 그 constructor가 해당 인스턴스의 자료구조에 영향을 끼치나요? 잘 판단해보시기 바랍니다. "강제로 재설정한 constructor 속성은 아무런 의미가 없습니다" 제 의도를 정리해드리죠. "인스턴스를 만들고 난 이후에 constructor를 재설정해도 그것은 이미 생성자로서의 의미를 가지지 못하며, 재설정되는 것은 단순히 자바스크립트의 유연성에서 비롯되는 것일 뿐이다. 따라서, "강제로 재설정한" constructor를 비교하는 것은 아무런 의미가 없다." 입니다. 유연함으로 인해 constructor 속성이 아무 값이라도 상관없이 재설정 할 수 있다는 것은 meat1.constructor = 1 이라는 예제를 통해서 이미 충분히 입증되었다고 생각합니다. 함수객체가 아닌 것도 constructor 속성에 설정될 수 있으니까요. "강제 재설정" 자체가 의미가 없다는 겁니다. "생성자가 곧 객체타입"이라 했습니다. 그렇다면, constructor를 재설정해서 객체타입이 변하느냐... 그게 아니라는 겁니다. 그래서 그렇게 바꾼 constructor는 아무런 의미도 없다는 것을 바로 위에서 말씀드렸습니다. 오히려 constructor를 바꿔도 최초의 생성자가 여전히 해당 인스턴스에 영향을 미치고 있음을 알 수 있습니다. 이제 다시 물어보겠습니다. 왜 강제로 재설정한 constructor를 비교하신건가요? 그 constructor가 해당 인스턴스의 자료구조에 영향을 끼치나요? 잘 판단해보시기 바랍니다. "강제로 재설정한 constructor 속성은 아무런 의미가 없습니다"

무소레즈   07-03-28 12:14   (객체.constructor) 이나  (A instanceof B) 등이 어디에 어떤 상황에서 사용될 수 있는지 생각해보세요.. 스스로 생각하는 시간을 가져야 하지 않겠습니까? 자신이 사용해보거나 직접 프로그램에 적용시켜 본적이 없다고 의미가 없다고 얘기하는것은  바람직하지 않겠지요. 뭣에 쓰는 물건인고... 내지는 뭣에 쓸꼬...를 생각해보세요. 의미가 없다는 말은 그 다음에 해도 늦지 않을까 합니다. (객체.constructor) 이나 (A instanceof B) 등이 어디에 어떤 상황에서 사용될 수 있는지 생각해보세요.. 스스로 생각하는 시간을 가져야 하지 않겠습니까? 자신이 사용해보거나 직접 프로그램에 적용시켜 본적이 없다고 의미가 없다고 얘기하는것은 바람직하지 않겠지요. 뭣에 쓰는 물건인고... 내지는 뭣에 쓸꼬...를 생각해보세요. 의미가 없다는 말은 그 다음에 해도 늦지 않을까 합니다.

행복한고니   07-03-28 12:19   전 하루종일 자바스크립트만 생각하는 사람이니까 저한테 생각해보라고 하지마시고요, 대화를 하시려면, 뭐가 자신의 의도인지 밝히시던지 제가 오해하고 있다면 어느 부분이 오해인지 말씀을 하셔야죠. 대화를 하실 생각이 아니라면 그만 두셔도 상관없습니다. 전 하루종일 자바스크립트만 생각하는 사람이니까 저한테 생각해보라고 하지마시고요, 대화를 하시려면, 뭐가 자신의 의도인지 밝히시던지 제가 오해하고 있다면 어느 부분이 오해인지 말씀을 하셔야죠. 대화를 하실 생각이 아니라면 그만 두셔도 상관없습니다.

무소레즈   07-03-28 12:27   대화할 생각이 없다기 보다는 더 이상의 대화는 필요하지 않을 것 같습니다. 어떤 목적으로 소스를 보여드린것이지 미리 얘기해 주었고, 몇줄 되지도 않는 소스의 의미 파악도 안되는 상황인듯 싶은데.. 더 진행이 되겠습니까? 대화할 생각이 없다기 보다는 더 이상의 대화는 필요하지 않을 것 같습니다. 어떤 목적으로 소스를 보여드린것이지 미리 얘기해 주었고, 몇줄 되지도 않는 소스의 의미 파악도 안되는 상황인듯 싶은데.. 더 진행이 되겠습니까?

행복한고니   07-03-28 13:33   글쎄요... 저 위에 보면 생성자라는 개념을 혼동하고 있으신 것 같아서 말이죠. constructor를 강제로 재설정했다고 constructor 속성에 있는 값이 생성자인 것은 아니라고 말씀드렸는데, 그게 생성자라고 말하고 계시는 것 같거든요. 그 전에는 인스턴스와 인스턴스 객체라는 용어를 다른 개념으로 사용하셨는데, 이것 역시 개념을 혼동하고 계시는 것 같다라는 말씀밖에는 더 드릴게 없습니다. 어쨌건 제가 보기에는 개념 자체를 혼동하시는 것 같으니 더 이상 얘기를 나눠봤자 진전이 없을 것 같습니다. 대화를 더 나눠봐야 진행이 안될 것 같다는 데는 동의합니다. 글쎄요... 저 위에 보면 생성자라는 개념을 혼동하고 있으신 것 같아서 말이죠. constructor를 강제로 재설정했다고 constructor 속성에 있는 값이 생성자인 것은 아니라고 말씀드렸는데, 그게 생성자라고 말하고 계시는 것 같거든요. 그 전에는 인스턴스와 인스턴스 객체라는 용어를 다른 개념으로 사용하셨는데, 이것 역시 개념을 혼동하고 계시는 것 같다라는 말씀밖에는 더 드릴게 없습니다. 어쨌건 제가 보기에는 개념 자체를 혼동하시는 것 같으니 더 이상 얘기를 나눠봤자 진전이 없을 것 같습니다. 대화를 더 나눠봐야 진행이 안될 것 같다는 데는 동의합니다.

무소레즈   07-03-28 15:05   생성자 개념을 혼동하는 부분이 어느 부분인지 구체적으로 말씀해보세요. (객체.constructor) 에의해 다른 객체타입의 construtor 속성값이 재할당 되도록 소스에 구현되어 있으나 그것이 생성자인것으로 생각하고 있는 것은  행복한 고니님입니다. 제공해 준 소스에서 생성자는 무엇이고, 인스턴스는 무엇이고, 어떤 객체 타입을 가졌고 그 결과가 제대로 나온것인지, 아니면 결과에 무엇이 잘못되었는지 설명 할 수 있다면 해보시기 바랍니다. 인스턴스와 인스턴스 개체라는 용어의 정의도 그렇습니다. 용어의 표현이 서로 다르다 할지라도 그 본질적인 의미가 같지 않다면 누군가 잘못 알고 있는 것이겠지요. 막연하게 잘못되었다느니... 개념을 혼동한다느니...라는 표현보다 님은 어떻게 생각하고 있는지를 밝힌다음에 어느 부분이 어떻게 다르고, 님은 어떻게 생각한다....라고 표현해야 하지 않겠습니까? 막연한 말로 말씨름 하기엔 어린 나이가 아닐텐데 말입니다. 그리고... 님의 반론에대한 반론으로 소스를 보여주었고... 윗쪽 많은 답변성 글들중에는 님이 소스의 검증을 해보고 난 후 문제점을 테스트용 소스로 간략하게나마 제시하던데.. 제가 제시한 소스에서는 어떤 문제로 인해 어떤 결과가 잘못 출력되었나요? 소스를 제공했으면,  로직이 잘못되었다던가? 결과가 바르게 출력되지 않는다던가... 기타 여러가지 문제점을 제시해야 하지 않는가요? 말로 다 채우려하지 말고, 제공한 소스로 직접 로직을 구현해보고, 점검해 본후 문제점을 지적해줄 님의 소스를 제시해 보시기 바랍니다. 또한, 님이 언급한..     "강제로 재설정한" constructor를 비교하는 것은 아무런 의미가 없다" 라는 말처럼  의미가 없으면 그 부분도 지우고 테스트를 해본후 함께 소견을 밝혀보시기 바랍니다.   "왜 강제로 재설정한 constructor를 비교하신건가요?   그 constructor가 해당 인스턴스의 자료구조에 영향을 끼치나요?   잘 판단해보시기 바랍니다." 라는 억지성 의견은 말고 말입니다. 뺄 부분은 빼고 테스트를 해보고, 빼거나 그대로 두거나 결과가 같다면 그냥 빼면 됩니다. 만약 결과가 다르다면 그것이 의미하는 바가 있겠지요. 생성자 개념을 혼동하는 부분이 어느 부분인지 구체적으로 말씀해보세요. (객체.constructor) 에의해 다른 객체타입의 construtor 속성값이 재할당 되도록 소스에 구현되어 있으나 그것이 생성자인것으로 생각하고 있는 것은 행복한 고니님입니다. 제공해 준 소스에서 생성자는 무엇이고, 인스턴스는 무엇이고, 어떤 객체 타입을 가졌고 그 결과가 제대로 나온것인지, 아니면 결과에 무엇이 잘못되었는지 설명 할 수 있다면 해보시기 바랍니다. 인스턴스와 인스턴스 개체라는 용어의 정의도 그렇습니다. 용어의 표현이 서로 다르다 할지라도 그 본질적인 의미가 같지 않다면 누군가 잘못 알고 있는 것이겠지요. 막연하게 잘못되었다느니... 개념을 혼동한다느니...라는 표현보다 님은 어떻게 생각하고 있는지를 밝힌다음에 어느 부분이 어떻게 다르고, 님은 어떻게 생각한다....라고 표현해야 하지 않겠습니까? 막연한 말로 말씨름 하기엔 어린 나이가 아닐텐데 말입니다. 그리고... 님의 반론에대한 반론으로 소스를 보여주었고... 윗쪽 많은 답변성 글들중에는 님이 소스의 검증을 해보고 난 후 문제점을 테스트용 소스로 간략하게나마 제시하던데.. 제가 제시한 소스에서는 어떤 문제로 인해 어떤 결과가 잘못 출력되었나요? 소스를 제공했으면, 로직이 잘못되었다던가? 결과가 바르게 출력되지 않는다던가... 기타 여러가지 문제점을 제시해야 하지 않는가요? 말로 다 채우려하지 말고, 제공한 소스로 직접 로직을 구현해보고, 점검해 본후 문제점을 지적해줄 님의 소스를 제시해 보시기 바랍니다. 또한, 님이 언급한.. "강제로 재설정한" constructor를 비교하는 것은 아무런 의미가 없다" 라는 말처럼 의미가 없으면 그 부분도 지우고 테스트를 해본후 함께 소견을 밝혀보시기 바랍니다. "왜 강제로 재설정한 constructor를 비교하신건가요? 그 constructor가 해당 인스턴스의 자료구조에 영향을 끼치나요? 잘 판단해보시기 바랍니다." 라는 억지성 의견은 말고 말입니다. 뺄 부분은 빼고 테스트를 해보고, 빼거나 그대로 두거나 결과가 같다면 그냥 빼면 됩니다. 만약 결과가 다르다면 그것이 의미하는 바가 있겠지요.

행복한고니   07-03-28 16:47   용어에 대한 제 생각은 저 위에 적었습니다. 텀즈 링크까지 드렸습니다. 상대방의 글을 제대로 읽으라면서요... -_-;;; 제가 생각하는 코드도 드렸습니다. 그랬더니 빗나간다고 하시던데요. 강제로 재설정한 constructor가 자료구조에 영향을 미치는 지에 대해서도 "그렇지않다"라고 증명하는 코드도 역시 드렸습니다. 그 뒤에 저한테 무슨 답글을 다셨는지 잘 보세요. 님이 말씀하시는 모든 것들을 이미 코드로도, 말로도 설명했습니다. 님의 글에 대한 제 글들을 잘 보세요. 어째서 강제로 설정한 constructor가 의미가 없는지에 대해서 남겼습니다. 그게 아니라면 저~~기 아래에 숨어지내리 님도 똑같은 착각을 하고 계시길래 근거를 남겨드렸습니다. 어떤 코드를 만들어드릴까요? 어떤 코드가 필요하신대요? 본인이 작성한 것을 이해못하면 제가 답답한 것이고 밥까지 먹여달라고 하는 격이고 글을 제대로 안 읽었다 하면, 제가 작성한 코드와 이미 했던 말을 이해못하거나 했는지도 모르고 계시는 님을 저는 어떻게 표현해야할까요. 인스턴스나 인스턴스 객체나 저에게 같은 말이고 인스턴스의 객체구조를 정의하는 것을 타입, 객체타입, 클래스 등으로 부릅니다. 클래스, 객체타입 등등은 추상적인 의미고요, 인스턴스는 실제로 사용할 수 있는 형태를 의미합니다. "생성자가 곧 객체타입" "consturctor 속성은 강제로 재정의 될 수 있으나 그게 진짜 생성자는 아니며, 따라서 강제로 설정된 값은 실제 객체구조에 아무런 영향도 미치지 못한다." 생성자가 곧 객체타입이 되는 것은 prototype 에 의해서입니다. function type1() {} var obj1 = new type1(); obj1.constructor = Date; 이렇게 바꿨을 때 obj1의 생성자가 Date이라면, Date의 prototype을 통해 속성을 지정했을 때, obj1에도 적용이 되어야 하지만 그렇지 않습니다. Date.prototype.cc = "c"; alert(obj1.cc); 하지만, type1에 지정하게 되면 obj1 에 적용이 됩니다. type1.prototype.bb = "b"; alert(obj1.bb); 왜 의미가 없느냐면, constructor  속성에 있는 것은 어떻게든 강제적으로 조작이 가능합니다. 지우는 것도 아무런 의미가 없는 값을 넣는 것도 가능합니다. 하지만, 이상한 값을 넣어도 constructor 속성을 삭제해도 여전히 obj1이 type1이라는 객체구조를 가지는 인스턴스 임에는 틀림이 없다는 말입니다. delete obj1.constructor; alert(obj1.constructor); type1.prototype.dd = "d"; alert(obj1.dd); 혹은 obj1.constructor = 1; alert(obj1.constructor); type1.prototype.ee = "e"; alert(obj1.ee); constructor 속성은 말 그대로 인스턴스 객체에 있는 속성일 뿐입니다. 그것을 강제로 지정하려면 할 수도 있습니다. 하지만 그렇다고 그게 객체의 성질을 규정하는 건 아니라는 거죠. 용어에 대한 제 생각은 저 위에 적었습니다. 텀즈 링크까지 드렸습니다. 상대방의 글을 제대로 읽으라면서요... -_-;;; 제가 생각하는 코드도 드렸습니다. 그랬더니 빗나간다고 하시던데요. 강제로 재설정한 constructor가 자료구조에 영향을 미치는 지에 대해서도 "그렇지않다"라고 증명하는 코드도 역시 드렸습니다. 그 뒤에 저한테 무슨 답글을 다셨는지 잘 보세요. 님이 말씀하시는 모든 것들을 이미 코드로도, 말로도 설명했습니다. 님의 글에 대한 제 글들을 잘 보세요. 어째서 강제로 설정한 constructor가 의미가 없는지에 대해서 남겼습니다. 그게 아니라면 저~~기 아래에 숨어지내리 님도 똑같은 착각을 하고 계시길래 근거를 남겨드렸습니다. 어떤 코드를 만들어드릴까요? 어떤 코드가 필요하신대요? 본인이 작성한 것을 이해못하면 제가 답답한 것이고 밥까지 먹여달라고 하는 격이고 글을 제대로 안 읽었다 하면, 제가 작성한 코드와 이미 했던 말을 이해못하거나 했는지도 모르고 계시는 님을 저는 어떻게 표현해야할까요. 인스턴스나 인스턴스 객체나 저에게 같은 말이고 인스턴스의 객체구조를 정의하는 것을 타입, 객체타입, 클래스 등으로 부릅니다. 클래스, 객체타입 등등은 추상적인 의미고요, 인스턴스는 실제로 사용할 수 있는 형태를 의미합니다. "생성자가 곧 객체타입" "consturctor 속성은 강제로 재정의 될 수 있으나 그게 진짜 생성자는 아니며, 따라서 강제로 설정된 값은 실제 객체구조에 아무런 영향도 미치지 못한다." 생성자가 곧 객체타입이 되는 것은 prototype 에 의해서입니다. function type1() {} var obj1 = new type1(); obj1.constructor = Date; 이렇게 바꿨을 때 obj1의 생성자가 Date이라면, Date의 prototype을 통해 속성을 지정했을 때, obj1에도 적용이 되어야 하지만 그렇지 않습니다. Date.prototype.cc = "c"; alert(obj1.cc); 하지만, type1에 지정하게 되면 obj1 에 적용이 됩니다. type1.prototype.bb = "b"; alert(obj1.bb); 왜 의미가 없느냐면, constructor 속성에 있는 것은 어떻게든 강제적으로 조작이 가능합니다. 지우는 것도 아무런 의미가 없는 값을 넣는 것도 가능합니다. 하지만, 이상한 값을 넣어도 constructor 속성을 삭제해도 여전히 obj1이 type1이라는 객체구조를 가지는 인스턴스 임에는 틀림이 없다는 말입니다. delete obj1.constructor; alert(obj1.constructor); type1.prototype.dd = "d"; alert(obj1.dd); 혹은 obj1.constructor = 1; alert(obj1.constructor); type1.prototype.ee = "e"; alert(obj1.ee); constructor 속성은 말 그대로 인스턴스 객체에 있는 속성일 뿐입니다. 그것을 강제로 지정하려면 할 수도 있습니다. 하지만 그렇다고 그게 객체의 성질을 규정하는 건 아니라는 거죠.

무소레즈   07-03-28 17:53   '강제로 재설정한 constructor가 자료구조에 영향을 미치는 지에 대해서도 "그렇지않다"라고 증명하는 코드도 역시 드렸습니다.' 라고 하셨는데...그것때문에 제가 제시한 소스코드에 어떤 문제점이 있는것인가요? 제 소스와 실행결과가 잘못된것이 있는데 그 이유가 강제로 재설정한 constructor 가 자료구조에 영향을 미치지 않기때문이라는 것인가요? 어떻게 결과가 나와야 제대로 나오는것인지에 대한 얘기는 없군요. constructor 속성의 강제 설정이 의미가 없다고 하면서 제시한 소스와 관련하여 그렇게 의미없는 얘기를 중점적으로 하는 이유라도 있어야 하지 않을까요? 유연성 얘기를 많이 꺼내시는데... 그 유연성을 활용하여 실행 처리하면 무엇이 잘못됩니까? 주어진 유연성을 활용하여 나름대로의 의미를 부여하며 처리하여 올바른 결과물을 가져와도 잘못된 것이라는 듯한 뉘앙스를 주는군요. constructor 속성의 값에 수나 문자열을 할당시키던, 객체를 할당 시키던 그것이 프로그램 처리에 있어서 무슨 문제를 일으킨다는 것인가요? 행복한고니님의 그런 저런 증명이나 길고 긴 부연설명들이 모두 그러..그러하다는 얘기들일뿐 반론으로써 제시한 소스에 대해서는  도대체 무슨 문제 있고, 실행 결과 값이 어떻게 틀린지등에대한  실질적인 언급이 없다는 것입니다. 의미 없는 constructor 재설정 얘기로 끝내지 말고,  그런 의미 없는 것으로 인해  소스코드의 실행에 어떤 문제가 있는것인지를 얘기할 수 있어야 하지 않을까 합니다. 정의가 어떻고 어떠하다....라는 말로 끝내고는 무슨 얘기가 진행이 됩니까? 스스로 의미없다고 하는 것들에대해 너무 집착하고 있는 것은 아닌가요? 아니면... 그 의미 없다고 얘기한 것이 없어져 줘야만.. 님이 주장하고 싶은 것들을 다시 피력할 수 있기 때문인가요? 윗쪽 답변글들중에서는  constructor 속성과 instanceof 연산자를 이용하여 여러가지 체크와 문제점을 제기했었는데... 제가 제시한 소스의 실행결과에서는 그것만으로 문제점을 찾을 수가 없던가요? 님의 답변글에는 제 소스의 로직과 실행의 문제점에 대한 실질적인 얘기가 어디에 표현되어 있는지 찾을 길이 없습니다. 대부분 정의와 관련 테스트 예들 뿐입니다. 어찌 엉뚱한 대답이 아닐 수 있겠습니까? '강제로 재설정한 constructor가 자료구조에 영향을 미치는 지에 대해서도 "그렇지않다"라고 증명하는 코드도 역시 드렸습니다.' 라고 하셨는데...그것때문에 제가 제시한 소스코드에 어떤 문제점이 있는것인가요? 제 소스와 실행결과가 잘못된것이 있는데 그 이유가 강제로 재설정한 constructor 가 자료구조에 영향을 미치지 않기때문이라는 것인가요? 어떻게 결과가 나와야 제대로 나오는것인지에 대한 얘기는 없군요. constructor 속성의 강제 설정이 의미가 없다고 하면서 제시한 소스와 관련하여 그렇게 의미없는 얘기를 중점적으로 하는 이유라도 있어야 하지 않을까요? 유연성 얘기를 많이 꺼내시는데... 그 유연성을 활용하여 실행 처리하면 무엇이 잘못됩니까? 주어진 유연성을 활용하여 나름대로의 의미를 부여하며 처리하여 올바른 결과물을 가져와도 잘못된 것이라는 듯한 뉘앙스를 주는군요. constructor 속성의 값에 수나 문자열을 할당시키던, 객체를 할당 시키던 그것이 프로그램 처리에 있어서 무슨 문제를 일으킨다는 것인가요? 행복한고니님의 그런 저런 증명이나 길고 긴 부연설명들이 모두 그러..그러하다는 얘기들일뿐 반론으로써 제시한 소스에 대해서는 도대체 무슨 문제 있고, 실행 결과 값이 어떻게 틀린지등에대한 실질적인 언급이 없다는 것입니다. 의미 없는 constructor 재설정 얘기로 끝내지 말고, 그런 의미 없는 것으로 인해 소스코드의 실행에 어떤 문제가 있는것인지를 얘기할 수 있어야 하지 않을까 합니다. 정의가 어떻고 어떠하다....라는 말로 끝내고는 무슨 얘기가 진행이 됩니까? 스스로 의미없다고 하는 것들에대해 너무 집착하고 있는 것은 아닌가요? 아니면... 그 의미 없다고 얘기한 것이 없어져 줘야만.. 님이 주장하고 싶은 것들을 다시 피력할 수 있기 때문인가요? 윗쪽 답변글들중에서는 constructor 속성과 instanceof 연산자를 이용하여 여러가지 체크와 문제점을 제기했었는데... 제가 제시한 소스의 실행결과에서는 그것만으로 문제점을 찾을 수가 없던가요? 님의 답변글에는 제 소스의 로직과 실행의 문제점에 대한 실질적인 얘기가 어디에 표현되어 있는지 찾을 길이 없습니다. 대부분 정의와 관련 테스트 예들 뿐입니다. 어찌 엉뚱한 대답이 아닐 수 있겠습니까?

TP™ 아쿠아   07-03-28 12:07   음.............. 이거 다 이해하면 고수대열에 끼이는건가요 -_-; 장장 40분에 걸쳐서 읽었네요 -ㅅ-; 음.............. 이거 다 이해하면 고수대열에 끼이는건가요 -_-; 장장 40분에 걸쳐서 읽었네요 -ㅅ-;

숨어지내리   07-03-28 13:53   ^^ 고생하셨습니다. ^^ 고생하셨습니다.

낭망백수   07-03-28 13:35   무소레즈 // (쪽지가 안되서 여기다 씁니다) 커멘트중에 자신의 커멘트는 삭제했으면 좋겠다고 의견을 피력하셨는데요. 괜찮으시다면, 삭제하지 않았으면 좋겠습니다. 혹시나 삭제될까봐 심히 염려가 되는군요. ^^;;; 무소레즈 // (쪽지가 안되서 여기다 씁니다) 커멘트중에 자신의 커멘트는 삭제했으면 좋겠다고 의견을 피력하셨는데요. 괜찮으시다면, 삭제하지 않았으면 좋겠습니다. 혹시나 삭제될까봐 심히 염려가 되는군요. ^^;;;

TP™ 아쿠아   07-03-28 13:52   저두요.... 삭제되면 아까워요 저두요.... 삭제되면 아까워요

숨어지내리   07-03-28 14:42   왠만하면 안달려고 했습니다. ^^ 이미 어느정도 제가 주장하고 있는 내용을 보여드렸으니깐요. 헌데, 고니님이 수긍하시지 않는 모습이 정말 이렇게 글을 남기게 되는군요. 자 이 모든건 제가 처음부터 말씀드렸던 prototype chain 으로 설명이 가능합니다. ---------------------------------------------------------------------------------- 1. 일단 2차 상속이라는게 자바스크립트에는 없습니다. 설명은 위에서 밝혔으니 따로 하지 않겠습니다(코드만 봐도 충분하다 봅니다). 따라서 constructor 를 두번 비교하는 것은 위에서 제가 말했던 대로 님의 착각에서 비롯된 것입니다. 2. constructor 는 해당 인스턴스의 객체구조를 알 수 있게 합니다. 이 때 객체구조의 정의는 반드시 Function의 인스턴스여야 합니다. ---------------------------------------------------------------------------------- 위의 내용은 고니님이 직접 정리한 내용입니다. Object 는 최상위라는것만 증명이 되면 고니님이 '주관적으로' 생각하는 아래의 내용 'Function 의 instance 여야만 합니다.' 라는게 거짓이 되는것입니다. Constructor 로 비교하는것 자체가 무리다 라는것이 입증되면, 고니님은 인정을 하실수밖에 없습니다. 즉, 제가 말한 'constructor 로 객체를 비교하는것 자체가 무리가 있다'라는 것입니다. 아래의 코드를 봐주십시요. alert(delete Function.prototype.constructor); alert(new Function().constructor.constructor); alert(new Object().constructor.constructor); alert(new Array().constructor.constructor); alert(new Number().constructor.constructor); alert(new String().constructor.constructor); alert(String.constructor); alert(Function.constructor); alert(Object.constructor); alert(Array.constructor); alert(Number.constructor); ㅋㅋㅋ 위의 코드는 IE , Firefox 모두 동작합니다. 고니님.!!!! ㅋㅋ 위의 코드는 prototype chain 을 일부러 끊어 보았습니다. 그랬더니, 각각의 객체는 Object 라는 constructor 를 보여주기 시작합니다. 따라서, 최상위 객체는 Object 라는 것이 입증된 샘이며, Function 은 단지 prototype chain 을 구성하는것 입니다. Object 가 Function 의 instance 가 아니라는 것입니다. 그건 즉 , constructor 는 말그대로 생성자입니다. 생성한 근본이 누구인지를 말입니다. Object | Array - Number - String - Function ... 으로 되어 있고 각각의 Function 이라는 chain 으로 감싸서 서로 연결되도록 구성되어 있는것입니다. 그래서 constructor 로 객체를 비교하는것은 무리가 있다라는 것입니다. constructor 를 2번 비교하는것이랑 1번비교하는것이랑의 차이는 없습니다. ^^ 단지, 생성한 근본 객체를 보여주는것이니깐 그런거구나하고 참조만 하면 된다라는 것입니다.   고로, 고니님이 주장하는 1,2 의 항목이 거짓입니다. 그러면, 여태 주장한 모든 것은 '주관,고집' 으로 보이는 것입니다. ---------------------------------------------------------------------------------  검증되지 않은 지식을 가지고 있는 것도 아주 싫어합니다. --------------------------------------------------------------------------------- 따라서, 고니님은 고니님을 아주 싫어하는 것입니다. ㅡㅡ;;;; 이런게 논리고 , 응용입니다. 고니님.. 이제 고니님이 인정할것이라 생각하며, ----------------------------- 아뇨. 정말로 틀렸다는 것을 증명해주시기를 바라고 있습니다. 원하신다면 문서로 만들어서 대중의 심판을 받을 각오도 되어있습니다. 여태까지 주신 근거는 제가 아니라고 반박해드렸습니다. 애매한 태도로 제가 우긴 것처럼 하지 마시고요, 정확하게 논거를 들어주시기 바랍니다. 틀렸으면 깨끗이 인정을 하시던가 그렇지 않으면 "내부적으로는 다르다" 는 것에 대한 증거를 보여주셨으면 합니다. 지금과 같은 태도는 별로 바람직하지 않다고 봅니다. 본질을 흐렸다고 생각하지 않고 있는데, 본질은 무엇이며 어떻게 흐렸는지도 좀 알려주시고요. 인정하기 싫으신건지는 모르겠지만, 어쨌든 간곡히 부탁드립니다 ------------------------------- 위의 내용을 토대로 실행하여, 이제껏 말한 내용을 정의 하여 주실거라 생각합니다. ps. 전 고니님과 친하게 지내고 싶습니다.     토론으로 서로 감정을 나쁘게 하지 않았으면 하는 바램입니다. ps2. http://zeldign.com/tt/38  과 같이 생각하고 있고,       동의하시는분들은 똑같다라는 표현은 다소 무리가 있다라고 생각해 주시면 감사하겠습니다. 왠만하면 안달려고 했습니다. ^^ 이미 어느정도 제가 주장하고 있는 내용을 보여드렸으니깐요. 헌데, 고니님이 수긍하시지 않는 모습이 정말 이렇게 글을 남기게 되는군요. 자 이 모든건 제가 처음부터 말씀드렸던 prototype chain 으로 설명이 가능합니다. ---------------------------------------------------------------------------------- 1. 일단 2차 상속이라는게 자바스크립트에는 없습니다. 설명은 위에서 밝혔으니 따로 하지 않겠습니다(코드만 봐도 충분하다 봅니다). 따라서 constructor 를 두번 비교하는 것은 위에서 제가 말했던 대로 님의 착각에서 비롯된 것입니다. 2. constructor 는 해당 인스턴스의 객체구조를 알 수 있게 합니다. 이 때 객체구조의 정의는 반드시 Function의 인스턴스여야 합니다. ---------------------------------------------------------------------------------- 위의 내용은 고니님이 직접 정리한 내용입니다. Object 는 최상위라는것만 증명이 되면 고니님이 '주관적으로' 생각하는 아래의 내용 'Function 의 instance 여야만 합니다.' 라는게 거짓이 되는것입니다. Constructor 로 비교하는것 자체가 무리다 라는것이 입증되면, 고니님은 인정을 하실수밖에 없습니다. 즉, 제가 말한 'constructor 로 객체를 비교하는것 자체가 무리가 있다'라는 것입니다. 아래의 코드를 봐주십시요. alert(delete Function.prototype.constructor); alert(new Function().constructor.constructor); alert(new Object().constructor.constructor); alert(new Array().constructor.constructor); alert(new Number().constructor.constructor); alert(new String().constructor.constructor); alert(String.constructor); alert(Function.constructor); alert(Object.constructor); alert(Array.constructor); alert(Number.constructor); ㅋㅋㅋ 위의 코드는 IE , Firefox 모두 동작합니다. 고니님.!!!! ㅋㅋ 위의 코드는 prototype chain 을 일부러 끊어 보았습니다. 그랬더니, 각각의 객체는 Object 라는 constructor 를 보여주기 시작합니다. 따라서, 최상위 객체는 Object 라는 것이 입증된 샘이며, Function 은 단지 prototype chain 을 구성하는것 입니다. Object 가 Function 의 instance 가 아니라는 것입니다. 그건 즉 , constructor 는 말그대로 생성자입니다. 생성한 근본이 누구인지를 말입니다. Object | Array - Number - String - Function ... 으로 되어 있고 각각의 Function 이라는 chain 으로 감싸서 서로 연결되도록 구성되어 있는것입니다. 그래서 constructor 로 객체를 비교하는것은 무리가 있다라는 것입니다. constructor 를 2번 비교하는것이랑 1번비교하는것이랑의 차이는 없습니다. ^^ 단지, 생성한 근본 객체를 보여주는것이니깐 그런거구나하고 참조만 하면 된다라는 것입니다. 고로, 고니님이 주장하는 1,2 의 항목이 거짓입니다. 그러면, 여태 주장한 모든 것은 '주관,고집' 으로 보이는 것입니다. --------------------------------------------------------------------------------- 검증되지 않은 지식을 가지고 있는 것도 아주 싫어합니다. --------------------------------------------------------------------------------- 따라서, 고니님은 고니님을 아주 싫어하는 것입니다. ㅡㅡ;;;; 이런게 논리고 , 응용입니다. 고니님.. 이제 고니님이 인정할것이라 생각하며, ----------------------------- 아뇨. 정말로 틀렸다는 것을 증명해주시기를 바라고 있습니다. 원하신다면 문서로 만들어서 대중의 심판을 받을 각오도 되어있습니다. 여태까지 주신 근거는 제가 아니라고 반박해드렸습니다. 애매한 태도로 제가 우긴 것처럼 하지 마시고요, 정확하게 논거를 들어주시기 바랍니다. 틀렸으면 깨끗이 인정을 하시던가 그렇지 않으면 "내부적으로는 다르다" 는 것에 대한 증거를 보여주셨으면 합니다. 지금과 같은 태도는 별로 바람직하지 않다고 봅니다. 본질을 흐렸다고 생각하지 않고 있는데, 본질은 무엇이며 어떻게 흐렸는지도 좀 알려주시고요. 인정하기 싫으신건지는 모르겠지만, 어쨌든 간곡히 부탁드립니다 ------------------------------- 위의 내용을 토대로 실행하여, 이제껏 말한 내용을 정의 하여 주실거라 생각합니다. ps. 전 고니님과 친하게 지내고 싶습니다. 토론으로 서로 감정을 나쁘게 하지 않았으면 하는 바램입니다. ps2. http://zeldign.com/tt/38 과 같이 생각하고 있고, 동의하시는분들은 똑같다라는 표현은 다소 무리가 있다라고 생각해 주시면 감사하겠습니다.

행복한고니   07-03-28 16:04   에휴... 안타깝습니다. 진짜... 자바스크립트를 제대로 좀 이해하세요. 테스트 할 때는 본인 주장에 맞는 것만 하고서 "맞다"라고 하지말고, 제가 반론할 수 있는 여지까지 테스트해주시기 바랍니다. -_-;; 제발... 번호 붙여 순서대로 증명할테니, 여기부터 이상하다 싶은 명제가 있으면 번호를 알려주세요. 1. 어떤 객체의 constructor는 생성후 자유롭게 조작가능합니다. 그건 위에서 무소레즈님과 대화할 때 말씀드렸으니 따로 더 말 안하겠습니다. (new Object).constructor = 1; 처럼 성질에 관계없이 값을 넣는 것도 가능합니다. 2. Function.prototype 은 함수의 인스턴스입니다. 물론, 확인하셨겠죠? FF에서는 그냥 함수 객체처럼, IE에서는 prototype이라는 이름을 가진 함수로 나타납니다. 3. 1번에 의해서 함수인스턴스의 constructor 속성은 또한 삭제할 수 있습니다. 하지만, 삭제가 되지는 않고 대신 Object 가 설정됩니다. 이 부분은 특이한 동작임이 확실합니다. 하지만 단지 재설정되었을 뿐입니다. 다른 객체에서는 constructor 속성이 삭제가능함을 굳이 증명하지 않겠습니다. 4. Object, Array, String... 등의 함수 인스턴스의 생성자인 Function에 prototype에 있는 속성값이 변경되었습니다. 따라서 Object... 등에 적용이 됩니다. 자 이제, Object, Array, String... 등은 constructor 속성으로 Object를 가지게 되었습니다. 5. 그렇다면 또 증명할 게 남았죠. constructor 속성이 Object라고 해서 Object는 더이상 Function의 인스턴스가 아닐까? 하는거죠. delete Function.prototype.constructor; alert(Object instanceof Function); 이걸로는 좀 부족하신가요? ^^ 하나더. 객체에는 constructor 뿐만 아니라, 생성자의 prototype을 알 수 있는 __proto__ 라는 속성도 있습니다. 아... JScript에는 없더군요. alert(Object.__proto__ === Function.prototype); alert(Object.__proto__ === Object.prototype); alert(Array.__proto__ === Function.prototype); alert(Array.__proto__ === Object.prototype); 이런... 이제 어쩔까요? ^^ 여전히 Function이 생성자인 것처럼 되어있군요. 6. 아직도 부족하시다면 그 끊었다던 prototype chain을 한번 이용해볼까요? Function.prototype.fool = "you"; alert(Object.fool); alert(Array.fool); 어라? 여전히 적용이 되네요? 님의 주장대로라면 Function은 생성자가 아니어야 할텐데 말이죠. ^^ 7. 결론. 님이 하신 것은 단순히 Function.prototype 이라는 함수 인스턴스에 있는 constructor 속성값을 지웠을 뿐입니다. 분명 지워진 자리가 undefined가 아닌 Object로 다시 복구되는 것은 특이한 일입니다(사용자 정의 객체에서는 undefined가 되죠). 하지만 그렇다해도 그것은 단지 constructor  속성이 재정의된 것에 불과할 뿐, 그게 constructor 속성에 있는 것이 생성자라는 뜻은 아닙니다. 여전히 내장객체들의 생성자는 Function 입니다. 보너스. Function.prototype.constructor = 1; alert(Object.constructor); Object의 상위객체는  숫자 1일까요? ^^ 자바스크립트의 유연성 덕분에 가능한 코드를 테스트도 안해보고 이렇게 들이밀어서야 되겠습니까. ^^ 아.. 그리고, 저는 별로 안 친해지고 싶어요. :) 에휴... 안타깝습니다. 진짜... 자바스크립트를 제대로 좀 이해하세요. 테스트 할 때는 본인 주장에 맞는 것만 하고서 "맞다"라고 하지말고, 제가 반론할 수 있는 여지까지 테스트해주시기 바랍니다. -_-;; 제발... 번호 붙여 순서대로 증명할테니, 여기부터 이상하다 싶은 명제가 있으면 번호를 알려주세요. 1. 어떤 객체의 constructor는 생성후 자유롭게 조작가능합니다. 그건 위에서 무소레즈님과 대화할 때 말씀드렸으니 따로 더 말 안하겠습니다. (new Object).constructor = 1; 처럼 성질에 관계없이 값을 넣는 것도 가능합니다. 2. Function.prototype 은 함수의 인스턴스입니다. 물론, 확인하셨겠죠? FF에서는 그냥 함수 객체처럼, IE에서는 prototype이라는 이름을 가진 함수로 나타납니다. 3. 1번에 의해서 함수인스턴스의 constructor 속성은 또한 삭제할 수 있습니다. 하지만, 삭제가 되지는 않고 대신 Object 가 설정됩니다. 이 부분은 특이한 동작임이 확실합니다. 하지만 단지 재설정되었을 뿐입니다. 다른 객체에서는 constructor 속성이 삭제가능함을 굳이 증명하지 않겠습니다. 4. Object, Array, String... 등의 함수 인스턴스의 생성자인 Function에 prototype에 있는 속성값이 변경되었습니다. 따라서 Object... 등에 적용이 됩니다. 자 이제, Object, Array, String... 등은 constructor 속성으로 Object를 가지게 되었습니다. 5. 그렇다면 또 증명할 게 남았죠. constructor 속성이 Object라고 해서 Object는 더이상 Function의 인스턴스가 아닐까? 하는거죠. delete Function.prototype.constructor; alert(Object instanceof Function); 이걸로는 좀 부족하신가요? ^^ 하나더. 객체에는 constructor 뿐만 아니라, 생성자의 prototype을 알 수 있는 __proto__ 라는 속성도 있습니다. 아... JScript에는 없더군요. alert(Object.__proto__ === Function.prototype); alert(Object.__proto__ === Object.prototype); alert(Array.__proto__ === Function.prototype); alert(Array.__proto__ === Object.prototype); 이런... 이제 어쩔까요? ^^ 여전히 Function이 생성자인 것처럼 되어있군요. 6. 아직도 부족하시다면 그 끊었다던 prototype chain을 한번 이용해볼까요? Function.prototype.fool = "you"; alert(Object.fool); alert(Array.fool); 어라? 여전히 적용이 되네요? 님의 주장대로라면 Function은 생성자가 아니어야 할텐데 말이죠. ^^ 7. 결론. 님이 하신 것은 단순히 Function.prototype 이라는 함수 인스턴스에 있는 constructor 속성값을 지웠을 뿐입니다. 분명 지워진 자리가 undefined가 아닌 Object로 다시 복구되는 것은 특이한 일입니다(사용자 정의 객체에서는 undefined가 되죠). 하지만 그렇다해도 그것은 단지 constructor 속성이 재정의된 것에 불과할 뿐, 그게 constructor 속성에 있는 것이 생성자라는 뜻은 아닙니다. 여전히 내장객체들의 생성자는 Function 입니다. 보너스. Function.prototype.constructor = 1; alert(Object.constructor); Object의 상위객체는 숫자 1일까요? ^^ 자바스크립트의 유연성 덕분에 가능한 코드를 테스트도 안해보고 이렇게 들이밀어서야 되겠습니까. ^^ 아.. 그리고, 저는 별로 안 친해지고 싶어요. :)

숨어지내리   07-03-28 17:10   ㅋㅋㅋㅋㅋㅋ 재미있습니다. 또 자기주관을 설파하시네요.. __proto__ 와 prototype 이 같다고 생각하시나 보다.. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 그럼 상속된 객체에서는 왜 다른지 알려줘보시겠어요? alert(new Object().__proto__ === new Object().prototype); 이렇게 비교하는것이랑 alert(Object.constructor === Array.constructor); 무슨차이가 있나요? ㅡㅡ; 참어이가 없을 따름입니다. __proto__: which class prototype: define lower class and class methods. __proto__ is a reference to the prototype property. The __proto__ property determines the prototype chain used to return property values the value of the prototype property of the constructor function 고니님처럼 한다면, alert(delete Function.prototype.__proto__); 객체에 which class 처음 값을 그대로 유지하고 있습니다.  그러니 체인을 끊은것을 보여주는게 아니라 체인을 그대로 보여주고 있는 것입니다. Object 가 최상위라는걸 증명하는건 다음과 같이 증명됩니다. alert(Function.__proto__.__proto__.__proto__); // null alert(Function.__proto__.__proto__);        // Object alert(Object.prototype.__proto__); // null alert(Object.prototype);    // Object alert(Array.prototype.__proto__.__proto__); // null alert(Array.prototype.__proto__); // Object alert(String.prototype.__proto__.__proto__); // null alert(String.prototype.__proto__); // Object          alert(Object.prototype);    // Object 참고로 Firefox 에서 실행한 겁니다. 고니님.. ㅋㅋ ㅡㅡ;;; 따라서 alert(Function.__proto__.__proto__ === Object.prototype); alert(Array.__proto__.__proto__ === Object.prototype); 즉. Object 가 최상위라는 말입니다. ㅡㅡ; 무슨 상속을 받습니까?.. Function 은 prototype chain 만 구성한다니깐요.. ㅡㅡ; 친해지고 싶지 않다니, 에휴...^^; 소심하셔서 그런지...ㅋ 그럼 그렇게 하시지 않으셔도 됩니다. ^^ ps. 이 글을 보고 계시는 분들이 많을 거라 생각합니다. 허나, 제가 말씀드리고 싶은것은 행복한 고니님과 저는 싸우려고 이렇게 장문을 쓰는게 아닙니다. 행복한 고니님이 틀렸다고 반박하는게 아니라, 글을 쓰다보니, 감정이 이입되어 서로 기분이 상한게 사실입니다. 고니님이 주장하는부분은 일리가 있습니다. 허나 또 제가 생각하는게 달라서 댓글을 달아 나가는 것이니깐요.... 생각이 달라 이어지는 글이니, 그렇게만 생각해 주시면 감사하겠습니다. ^^ ㅋㅋㅋㅋㅋㅋ 재미있습니다. 또 자기주관을 설파하시네요.. __proto__ 와 prototype 이 같다고 생각하시나 보다.. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 그럼 상속된 객체에서는 왜 다른지 알려줘보시겠어요? alert(new Object().__proto__ === new Object().prototype); 이렇게 비교하는것이랑 alert(Object.constructor === Array.constructor); 무슨차이가 있나요? ㅡㅡ; 참어이가 없을 따름입니다. __proto__: which class prototype: define lower class and class methods. __proto__ is a reference to the prototype property. The __proto__ property determines the prototype chain used to return property values the value of the prototype property of the constructor function 고니님처럼 한다면, alert(delete Function.prototype.__proto__); 객체에 which class 처음 값을 그대로 유지하고 있습니다. 그러니 체인을 끊은것을 보여주는게 아니라 체인을 그대로 보여주고 있는 것입니다. Object 가 최상위라는걸 증명하는건 다음과 같이 증명됩니다. alert(Function.__proto__.__proto__.__proto__); // null alert(Function.__proto__.__proto__); // Object alert(Object.prototype.__proto__); // null alert(Object.prototype); // Object alert(Array.prototype.__proto__.__proto__); // null alert(Array.prototype.__proto__); // Object alert(String.prototype.__proto__.__proto__); // null alert(String.prototype.__proto__); // Object alert(Object.prototype); // Object 참고로 Firefox 에서 실행한 겁니다. 고니님.. ㅋㅋ ㅡㅡ;;; 따라서 alert(Function.__proto__.__proto__ === Object.prototype); alert(Array.__proto__.__proto__ === Object.prototype); 즉. Object 가 최상위라는 말입니다. ㅡㅡ; 무슨 상속을 받습니까?.. Function 은 prototype chain 만 구성한다니깐요.. ㅡㅡ; 친해지고 싶지 않다니, 에휴...^^; 소심하셔서 그런지...ㅋ 그럼 그렇게 하시지 않으셔도 됩니다. ^^ ps. 이 글을 보고 계시는 분들이 많을 거라 생각합니다. 허나, 제가 말씀드리고 싶은것은 행복한 고니님과 저는 싸우려고 이렇게 장문을 쓰는게 아닙니다. 행복한 고니님이 틀렸다고 반박하는게 아니라, 글을 쓰다보니, 감정이 이입되어 서로 기분이 상한게 사실입니다. 고니님이 주장하는부분은 일리가 있습니다. 허나 또 제가 생각하는게 달라서 댓글을 달아 나가는 것이니깐요.... 생각이 달라 이어지는 글이니, 그렇게만 생각해 주시면 감사하겠습니다. ^^

행복한고니   07-03-28 18:32   우선 제가 __proto__ 를 어떻게 사용했는지 좀 보세요. 이거야 원... Function을 Object의 생성자로 보고 증명하기 위해 사용한겁니다. 어떤객체.__proto__ === 어떤객체의생성자.prototype 이거든요? 그건 저~~기 위에도 썼던 얘깁니다. 제발 제 글 좀 읽으세요! 나참 코드를 이해못하고, 글도 안 읽고... 대체 뭘하자는 건지... -_-;; ___________________________________________________________ 일단은 나머지 예도 반박해주세요. 항상 일부만 반박하는 버릇이 있으시더군요. 아.. 아닙니다. 그냥 맞다고 혼자 생각하시고 답글 달지 마세요. 블로그에서 제 말이 틀렸다고 하시든지, 스쿨 팁텍에 정리해서 올리든지는 알아서 하시고요... 제 글 모니터링이 되서 답글달면 어쨌거나 제가 그 글을 봐야하니까 이 글에 답글달지 말고 자신의 세계를 계속 설파하세요. 팁으로 올리면 글쓴이 이름보고 자체필터링 할 수 있으니까요. 그렇게 해주세요. ___________________________________________________________ 그나저나 이 코드 어이가 없습니다. prototype은 왜 비교하는데요? 아... 진짜... Function.__proto__.__proto__ 값이 Object라고 이미 써놓고서는 Object.prototype 이랑 같다고 한건 또 뭔지... prototype chain을 가지고 거슬러 올라가면서 상속증명하려는 사람은 또 첨봤구요. Function.__proto__ 는 Function이라는객체의생성자의prototype입니다. 여기에 또 prototype을 쓰면서부터 말도 안되는 증명이 시작됩니다. prototype이라는 속성의 생성자를 비교해서 어쩌자고요? 제가 왜 한단계밖에 이해못하신거 같군요. 제가 __proto__를 사용했던 것은 __proto__가 위에서 제가 말한 것과 같기 때문에, "이 객체의 생성자가 무엇인지 확인해보기 위해 썼던 것"입니다. (new Object).__proto__ === Object.prototype; 이게 가능하다면 new Object는 Object라는 생성자로부터 만들어진게 맞다는 말이됩니다. ㅋㅋ 근데 왜 prototype 속성 자체의 타입을 비교하고 계시나요? ㅎㅎ 그게 여러번 사용되면 상속을 증명할 수 있게 되는건가요? ㅋㅋ Function.__proto__ <- 이거요? Function의생성자의prototype이죠. Function의 생성자가 뭔지 그것의 prototype이 뭔지 체크해보세요. (Function.__proto__) 여기부터는 function(){} 인스턴스를 가지고 또 다루겠네요. 님께서 하신 행동이요? 바로 그런겁니다. Function과 관계있는게 아니라 prototype 자체를 비교하고 있는 것이죠. 으하하하하~~  Array.prototype, Function.prototype 이런거 한번씩 찍어보셨죠? ㅎㅎ  prototype 속성의 생성자, 또  prototype의 속성 이런걸 따져서 어쩌자고요? ㅋㅋ IE에서도 할 수 있어요. __proto__ 대신에 constructor.prototype 을 치환하시면 됩니다. prototype 속성 자체를 거슬러 올라가서 어쩌자는 것인지 원... prototype chain에 대해서 잘 모르시는거 이미 알고 있으니 다시 상기시켜주지 않으셔도 됩니다. ___________________________________________________________ 아... 이해를 하셨건 못하셨건 또 저보고 우긴다고 할테니, 이젠 그만 혼자 노세요. ___________________________________________________________ 소심하기도 한데, 말귀도 못알아먹는 사람과는 어머니께서 친하게 지내지 말라더라군요. 우선 제가 __proto__ 를 어떻게 사용했는지 좀 보세요. 이거야 원... Function을 Object의 생성자로 보고 증명하기 위해 사용한겁니다. 어떤객체.__proto__ === 어떤객체의생성자.prototype 이거든요? 그건 저~~기 위에도 썼던 얘깁니다. 제발 제 글 좀 읽으세요! 나참 코드를 이해못하고, 글도 안 읽고... 대체 뭘하자는 건지... -_-;; ___________________________________________________________ 일단은 나머지 예도 반박해주세요. 항상 일부만 반박하는 버릇이 있으시더군요. 아.. 아닙니다. 그냥 맞다고 혼자 생각하시고 답글 달지 마세요. 블로그에서 제 말이 틀렸다고 하시든지, 스쿨 팁텍에 정리해서 올리든지는 알아서 하시고요... 제 글 모니터링이 되서 답글달면 어쨌거나 제가 그 글을 봐야하니까 이 글에 답글달지 말고 자신의 세계를 계속 설파하세요. 팁으로 올리면 글쓴이 이름보고 자체필터링 할 수 있으니까요. 그렇게 해주세요. ___________________________________________________________ 그나저나 이 코드 어이가 없습니다. prototype은 왜 비교하는데요? 아... 진짜... Function.__proto__.__proto__ 값이 Object라고 이미 써놓고서는 Object.prototype 이랑 같다고 한건 또 뭔지... prototype chain을 가지고 거슬러 올라가면서 상속증명하려는 사람은 또 첨봤구요. Function.__proto__ 는 Function이라는객체의생성자의prototype입니다. 여기에 또 prototype을 쓰면서부터 말도 안되는 증명이 시작됩니다. prototype이라는 속성의 생성자를 비교해서 어쩌자고요? 제가 왜 한단계밖에 이해못하신거 같군요. 제가 __proto__를 사용했던 것은 __proto__가 위에서 제가 말한 것과 같기 때문에, "이 객체의 생성자가 무엇인지 확인해보기 위해 썼던 것"입니다. (new Object).__proto__ === Object.prototype; 이게 가능하다면 new Object는 Object라는 생성자로부터 만들어진게 맞다는 말이됩니다. ㅋㅋ 근데 왜 prototype 속성 자체의 타입을 비교하고 계시나요? ㅎㅎ 그게 여러번 사용되면 상속을 증명할 수 있게 되는건가요? ㅋㅋ Function.__proto__ <- 이거요? Function의생성자의prototype이죠. Function의 생성자가 뭔지 그것의 prototype이 뭔지 체크해보세요. (Function.__proto__) 여기부터는 function(){} 인스턴스를 가지고 또 다루겠네요. 님께서 하신 행동이요? 바로 그런겁니다. Function과 관계있는게 아니라 prototype 자체를 비교하고 있는 것이죠. 으하하하하~~ Array.prototype, Function.prototype 이런거 한번씩 찍어보셨죠? ㅎㅎ prototype 속성의 생성자, 또 prototype의 속성 이런걸 따져서 어쩌자고요? ㅋㅋ IE에서도 할 수 있어요. __proto__ 대신에 constructor.prototype 을 치환하시면 됩니다. prototype 속성 자체를 거슬러 올라가서 어쩌자는 것인지 원... prototype chain에 대해서 잘 모르시는거 이미 알고 있으니 다시 상기시켜주지 않으셔도 됩니다. ___________________________________________________________ 아... 이해를 하셨건 못하셨건 또 저보고 우긴다고 할테니, 이젠 그만 혼자 노세요. ___________________________________________________________ 소심하기도 한데, 말귀도 못알아먹는 사람과는 어머니께서 친하게 지내지 말라더라군요.

숨어지내리   07-03-28 19:12   어떻게... 진짜.. 모르고 계셨네... ㅠㅠ; __proto__ 와 prototype 을 사용하는 방법을요.. ㅡㅡ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 그러면서 JAVASCIRPT 를 모른다고 운운하셨습니까 ?????? 아...일을 어쩐다냐...ㅡㅡ;  한심하기 그지 없습니다... ㅠㅠ 오늘로써 고니님의 대한 나의 생각을 다시 정리해야할것 같습니다... ㅡㅡ; http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Property_Inheritance_Revisited:Determining_Instance_Relationships 일단 , 위의 내용 보시고요 __proto__ 의 제대로된 내용을 공부하세요.!!! //======================================== --------------------------------------------------- alert(Function.__proto__.__proto__.__proto__); // null alert(Function.__proto__.__proto__);        // Object alert(Object.prototype.__proto__); // null alert(Object.prototype);    // Object alert(Array.prototype.__proto__.__proto__); // null alert(Array.prototype.__proto__); // Object alert(String.prototype.__proto__.__proto__); // null alert(String.prototype.__proto__); // Object         alert(Object.prototype);    // Object 참고로 Firefox 에서 실행한 겁니다. 고니님.. ㅋㅋ ㅡㅡ;;; 따라서 alert(Function.__proto__.__proto__ === Object.prototype); alert(Array.__proto__.__proto__ === Object.prototype); --------------------------------------------------- //======================================== 위의 코드를 이해를 못하시고 계시니 원... ㅡㅡ;; 이러니 말이 안통하죠.. --------------------------------------------------- Function.__proto__.__proto__ 값이 Object라고 이미 써놓고서는 Object.prototype 이랑 같다고 한건 또 뭔지... prototype chain을 가지고 거슬러 올라가면서 상속증명하려는 사람은 또 첨봤구요. --------------------------------------------------- 처음 보셨으니, 이제부터 계속 보실것입니다. .. 자 그럼 아래의 코드를 보세요. alert(Object.prototype.__proto__); // null -> function 의 상속이 아니다. 라는 증명 alert(Function.prototype.__proto__.__proto__); //null alert(Array.prototype.__proto__.__proto__); // null alert(String.prototype.__proto__.__proto__); // null 따라서 이렇게 되는 겁니다. alert(Object.prototype); // object alert(Function.prototype.__proto__); // object alert(Array.prototype.__proto__); // object alert(String.prototype.__proto__); // object 아직도 모르겠습니까? function(){} 은 chain 을 구성하는것 이라니깐요.. ㅡㅡ; 그래서 이렇게 증명된거고요..  Object 가 최상위이다.. 1. Object 는 Function 의 instance 가 아니다라고요..!!!! 2. Function 은 단지 prototype chain 만을 구성한다고 말하는것이고, 3. constructor로 비교하는것 자체가 무리이고요.. 자꾸만 왜 이상한 변명과 고집을 피는지 모르겠습니다. ㅡㅡ;;;; -------------------------------------------------------------------------------------- 말귀도 못알아먹는 사람과는 어머니께서 친하게 지내지 말라더라군요. -------------------------------------------------------------------------------------- 이젠 어머님의 말씀을 따라야 할것 같습니다. ㅠㅠ 따라서, 고니님의 주장은 모두 '주관,고집' 이라고 말하는것이고요.. ㅡㅡ; 제가 말한 아래의 내용이 되는것입니다. //======================================= 고로, 고니님이 주장하는 1,2 의 항목이 거짓입니다. 그러면, 여태 주장한 모든 것은 '주관,고집' 으로 보이는 것입니다. ---------------------------------------------------------------------------------  검증되지 않은 지식을 가지고 있는 것도 아주 싫어합니다. --------------------------------------------------------------------------------- 따라서, 고니님은 고니님을 아주 싫어하는 것입니다. ㅡㅡ;;;; 이런게 논리고 , 응용입니다. 고니님.. //======================================= 아.. 깝깝스럽습니다.. ㅠㅠ 왜 진실을 왜곡하면서 자신의 주관을 설파하는지... 고니님의 특징을 잘 보면 0. 자신의 주관을 사실인 양 말한다. 1. 하나 검증하면 , 또다른 숙제를 낸다. 2. 또 검증하면, 반박하며,  또다른 숙제를 낸다. 2.2 살짝 약올린다. 3. 막판까지 오면, 자신의 주장을 살짝 바꾼다. (브라우저문제, 버그 등등) 4. 아닌거 같으니, 이젠 답글을 그만 달라한다. ps. 그냥 진실이 왜곡되지 않았다면, 이런 긴 댓글은 없었을것입니다. 어떻게... 진짜.. 모르고 계셨네... ㅠㅠ; __proto__ 와 prototype 을 사용하는 방법을요.. ㅡㅡ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 그러면서 JAVASCIRPT 를 모른다고 운운하셨습니까 ?????? 아...일을 어쩐다냐...ㅡㅡ; 한심하기 그지 없습니다... ㅠㅠ 오늘로써 고니님의 대한 나의 생각을 다시 정리해야할것 같습니다... ㅡㅡ; http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Property_Inheritance_Revisited:Determining_Instance_Relationships 일단 , 위의 내용 보시고요 __proto__ 의 제대로된 내용을 공부하세요.!!! //======================================== --------------------------------------------------- alert(Function.__proto__.__proto__.__proto__); // null alert(Function.__proto__.__proto__); // Object alert(Object.prototype.__proto__); // null alert(Object.prototype); // Object alert(Array.prototype.__proto__.__proto__); // null alert(Array.prototype.__proto__); // Object alert(String.prototype.__proto__.__proto__); // null alert(String.prototype.__proto__); // Object alert(Object.prototype); // Object 참고로 Firefox 에서 실행한 겁니다. 고니님.. ㅋㅋ ㅡㅡ;;; 따라서 alert(Function.__proto__.__proto__ === Object.prototype); alert(Array.__proto__.__proto__ === Object.prototype); --------------------------------------------------- //======================================== 위의 코드를 이해를 못하시고 계시니 원... ㅡㅡ;; 이러니 말이 안통하죠.. --------------------------------------------------- Function.__proto__.__proto__ 값이 Object라고 이미 써놓고서는 Object.prototype 이랑 같다고 한건 또 뭔지... prototype chain을 가지고 거슬러 올라가면서 상속증명하려는 사람은 또 첨봤구요. --------------------------------------------------- 처음 보셨으니, 이제부터 계속 보실것입니다. .. 자 그럼 아래의 코드를 보세요. alert(Object.prototype.__proto__); // null -> function 의 상속이 아니다. 라는 증명 alert(Function.prototype.__proto__.__proto__); //null alert(Array.prototype.__proto__.__proto__); // null alert(String.prototype.__proto__.__proto__); // null 따라서 이렇게 되는 겁니다. alert(Object.prototype); // object alert(Function.prototype.__proto__); // object alert(Array.prototype.__proto__); // object alert(String.prototype.__proto__); // object 아직도 모르겠습니까? function(){} 은 chain 을 구성하는것 이라니깐요.. ㅡㅡ; 그래서 이렇게 증명된거고요.. Object 가 최상위이다.. 1. Object 는 Function 의 instance 가 아니다라고요..!!!! 2. Function 은 단지 prototype chain 만을 구성한다고 말하는것이고, 3. constructor로 비교하는것 자체가 무리이고요.. 자꾸만 왜 이상한 변명과 고집을 피는지 모르겠습니다. ㅡㅡ;;;; -------------------------------------------------------------------------------------- 말귀도 못알아먹는 사람과는 어머니께서 친하게 지내지 말라더라군요. -------------------------------------------------------------------------------------- 이젠 어머님의 말씀을 따라야 할것 같습니다. ㅠㅠ 따라서, 고니님의 주장은 모두 '주관,고집' 이라고 말하는것이고요.. ㅡㅡ; 제가 말한 아래의 내용이 되는것입니다. //======================================= 고로, 고니님이 주장하는 1,2 의 항목이 거짓입니다. 그러면, 여태 주장한 모든 것은 '주관,고집' 으로 보이는 것입니다. --------------------------------------------------------------------------------- 검증되지 않은 지식을 가지고 있는 것도 아주 싫어합니다. --------------------------------------------------------------------------------- 따라서, 고니님은 고니님을 아주 싫어하는 것입니다. ㅡㅡ;;;; 이런게 논리고 , 응용입니다. 고니님.. //======================================= 아.. 깝깝스럽습니다.. ㅠㅠ 왜 진실을 왜곡하면서 자신의 주관을 설파하는지... 고니님의 특징을 잘 보면 0. 자신의 주관을 사실인 양 말한다. 1. 하나 검증하면 , 또다른 숙제를 낸다. 2. 또 검증하면, 반박하며, 또다른 숙제를 낸다. 2.2 살짝 약올린다. 3. 막판까지 오면, 자신의 주장을 살짝 바꾼다. (브라우저문제, 버그 등등) 4. 아닌거 같으니, 이젠 답글을 그만 달라한다. ps. 그냥 진실이 왜곡되지 않았다면, 이런 긴 댓글은 없었을것입니다.

행복한고니   07-03-29 02:08   인용하신 MDC 문서에서 사용된 코드를 그대로 가져다 드리죠. ________________________________________ chris = new Engineer("Pigman, Chris", ["jsd"], "fiji"); chris.__proto__ == Engineer.prototype; ________________________________________ 위에서 보시면 아시겠지만 chirs가 Engineer의 인스턴스이기 때문에 chris.__proto__ 는 생성자인Engineer의 prototype이 됩니다. 아... 그리고  // Object 라고 표시한게 Object의 인스턴스더군요. 그렇다면, alert(Function.__proto__.__proto__ === Object.prototype); 이렇게 비교하는 것은 옳습니다. 이 부분은 제 실수가 맞네요. 하지만 제가 코드를 착각한 것이지 성질 자체를 착각한 것은 아닙니다. 주욱 위에서부터 읽어보세요. 계속 똑같은 얘기만 하고 있으니까요. 어쨌거나 위의 부분에서는 제가 실수했습니다. 하지만 왜 계속 __proto__ 를 물고 들어가는게 옳지 않은지는 뭐... 생각해보면 아시겠지만, 모르셔도 상관없습니다. ________________________________________ 자, 이제 또 제가 증명할 시간이 왔습니다. 이것저것 증명하다가 그래봐야 어차피 듣지도 않을 것이고 해서 싹 지우고 그냥 애초 생각대로 javascript 엔진을 까봤습니다. -_-;; 귀차니즘이 강한 저를 이렇게 하게까지 한 점은 정말 높이삽니다. 다운로드는 아래 주소에서 하세요. ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R5.zip 뭐... 제가 한 소스 분석이 마음에 안들면 직접 다 분석해보셔도 됩니다. :) 차근차근 따라가보면 알겠지만, 스크립트를 실행할 때 object literal 을 만드는 부분이 있습니다. ScriptRuntime.java의 3094 라인을 보세요. 잘 보시면 리턴하는 객체가 cx.newObject 라는 것에 의해 만들어지는 것을 알 수 있고, cx는 Context 타입임을 알 수 있습니다. 자.. 이제 Context.java 열어보시고요, 1404 라인 보세요. 주석에 떡하니 써있습니다. new Object를 실행하는 것과 equivalent 하다고 말이죠. ^^ equivalent의 뜻을 혹시 또 오해할까봐 밑에 있는 오버로딩 메소드들도 꼭! 같이 보라고 말씀드립니다. 다시 ScriptRuntime.java의 3098라인 보세요. 객체 만들고 나서 프로퍼티 할당하고 있는게 보이실 겁니다. 그리고 나서는 바로 객체를 리턴하는 것으로 보이네요.  이렇게 소스를 열어놓고 보니 둘이 왜 다르다고 하는지 더더욱 모르겠네요. :) 또한, 객체 만들고 프로퍼티를 설정하는 것을 더 편하게 해준거라는 제 주장에 더 힘이 실릴 것 같구요. ^^ ________________________________________ 이 글에 답글 안 달아도 되니까 애초에 생각하셨던 바와 그 근거를 팁으로 정리하셔서 부디 널리 퍼트리세요. :) 여러분의 판단을 위해서 해당 부분 소스를 첨부합니다. ################################### ## ScriptRuntime.java의 3094 라인부터 ################################### public static Scriptable newObjectLiteral(Object[] propertyIds,                                           Object[] propertyValues,                                           Context cx, Scriptable scope) {     Scriptable object = cx.newObject(scope);     for (int i = 0, end = propertyIds.length; i != end; ++i) {         Object id = propertyIds[i];         Object value = propertyValues[i];         if (id instanceof String) {             ScriptableObject.putProperty(object, (String)id, value);         } else {             int index = ((Integer)id).intValue();             ScriptableObject.putProperty(object, index, value);         }     }     return object; } ############################## ## Context.java 의 1396 라인부터 ############################## /**  * Create a new JavaScript object.  *  * Equivalent to evaluating "new Object()".  * @param scope the scope to search for the constructor and to evaluate  *              against  * @return the new object  */ public final Scriptable newObject(Scriptable scope) {     return newObject(scope, "Object", ScriptRuntime.emptyArgs); } /**  * Create a new JavaScript object by executing the named constructor.  *  * The call <code>newObject(scope, "Foo")</code> is equivalent to  * evaluating "new Foo()".  *  * @param scope the scope to search for the constructor and to evaluate against  * @param constructorName the name of the constructor to call  * @return the new object  */ public final Scriptable newObject(Scriptable scope, String constructorName) {     return newObject(scope, constructorName, ScriptRuntime.emptyArgs); } /**  * Creates a new JavaScript object by executing the named constructor.  *  * Searches <code>scope</code> for the named constructor, calls it with  * the given arguments, and returns the result.<p>  *  * The code  * <pre>  * Object[] args = { "a", "b" };  * newObject(scope, "Foo", args)</pre>  * is equivalent to evaluating "new Foo('a', 'b')", assuming that the Foo  * constructor has been defined in <code>scope</code>.  *  * @param scope The scope to search for the constructor and to evaluate  *              against  * @param constructorName the name of the constructor to call  * @param args the array of arguments for the constructor  * @return the new object  */ public final Scriptable newObject(Scriptable scope, String constructorName,                                   Object[] args) {     scope = ScriptableObject.getTopLevelScope(scope);     Function ctor = ScriptRuntime.getExistingCtor(this, scope,                                                   constructorName);     if (args == null) { args = ScriptRuntime.emptyArgs; }     return ctor.construct(this, scope, args); } 인용하신 MDC 문서에서 사용된 코드를 그대로 가져다 드리죠. ________________________________________ chris = new Engineer("Pigman, Chris", ["jsd"], "fiji"); chris.__proto__ == Engineer.prototype; ________________________________________ 위에서 보시면 아시겠지만 chirs가 Engineer의 인스턴스이기 때문에 chris.__proto__ 는 생성자인Engineer의 prototype이 됩니다. 아... 그리고 // Object 라고 표시한게 Object의 인스턴스더군요. 그렇다면, alert(Function.__proto__.__proto__ === Object.prototype); 이렇게 비교하는 것은 옳습니다. 이 부분은 제 실수가 맞네요. 하지만 제가 코드를 착각한 것이지 성질 자체를 착각한 것은 아닙니다. 주욱 위에서부터 읽어보세요. 계속 똑같은 얘기만 하고 있으니까요. 어쨌거나 위의 부분에서는 제가 실수했습니다. 하지만 왜 계속 __proto__ 를 물고 들어가는게 옳지 않은지는 뭐... 생각해보면 아시겠지만, 모르셔도 상관없습니다. ________________________________________ 자, 이제 또 제가 증명할 시간이 왔습니다. 이것저것 증명하다가 그래봐야 어차피 듣지도 않을 것이고 해서 싹 지우고 그냥 애초 생각대로 javascript 엔진을 까봤습니다. -_-;; 귀차니즘이 강한 저를 이렇게 하게까지 한 점은 정말 높이삽니다. 다운로드는 아래 주소에서 하세요. ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R5.zip 뭐... 제가 한 소스 분석이 마음에 안들면 직접 다 분석해보셔도 됩니다. :) 차근차근 따라가보면 알겠지만, 스크립트를 실행할 때 object literal 을 만드는 부분이 있습니다. ScriptRuntime.java의 3094 라인을 보세요. 잘 보시면 리턴하는 객체가 cx.newObject 라는 것에 의해 만들어지는 것을 알 수 있고, cx는 Context 타입임을 알 수 있습니다. 자.. 이제 Context.java 열어보시고요, 1404 라인 보세요. 주석에 떡하니 써있습니다. new Object를 실행하는 것과 equivalent 하다고 말이죠. ^^ equivalent의 뜻을 혹시 또 오해할까봐 밑에 있는 오버로딩 메소드들도 꼭! 같이 보라고 말씀드립니다. 다시 ScriptRuntime.java의 3098라인 보세요. 객체 만들고 나서 프로퍼티 할당하고 있는게 보이실 겁니다. 그리고 나서는 바로 객체를 리턴하는 것으로 보이네요. 이렇게 소스를 열어놓고 보니 둘이 왜 다르다고 하는지 더더욱 모르겠네요. :) 또한, 객체 만들고 프로퍼티를 설정하는 것을 더 편하게 해준거라는 제 주장에 더 힘이 실릴 것 같구요. ^^ ________________________________________ 이 글에 답글 안 달아도 되니까 애초에 생각하셨던 바와 그 근거를 팁으로 정리하셔서 부디 널리 퍼트리세요. :) 여러분의 판단을 위해서 해당 부분 소스를 첨부합니다. ################################### ## ScriptRuntime.java의 3094 라인부터 ################################### public static Scriptable newObjectLiteral(Object[] propertyIds, Object[] propertyValues, Context cx, Scriptable scope) { Scriptable object = cx.newObject(scope); for (int i = 0, end = propertyIds.length; i != end; ++i) { Object id = propertyIds[i]; Object value = propertyValues[i]; if (id instanceof String) { ScriptableObject.putProperty(object, (String)id, value); } else { int index = ((Integer)id).intValue(); ScriptableObject.putProperty(object, index, value); } } return object; } ############################## ## Context.java 의 1396 라인부터 ############################## /** * Create a new JavaScript object. * * Equivalent to evaluating "new Object()". * @param scope the scope to search for the constructor and to evaluate * against * @return the new object */ public final Scriptable newObject(Scriptable scope) { return newObject(scope, "Object", ScriptRuntime.emptyArgs); } /** * Create a new JavaScript object by executing the named constructor. * * The call <code>newObject(scope, "Foo")</code> is equivalent to * evaluating "new Foo()". * * @param scope the scope to search for the constructor and to evaluate against * @param constructorName the name of the constructor to call * @return the new object */ public final Scriptable newObject(Scriptable scope, String constructorName) { return newObject(scope, constructorName, ScriptRuntime.emptyArgs); } /** * Creates a new JavaScript object by executing the named constructor. * * Searches <code>scope</code> for the named constructor, calls it with * the given arguments, and returns the result.<p> * * The code * <pre> * Object[] args = { "a", "b" }; * newObject(scope, "Foo", args)</pre> * is equivalent to evaluating "new Foo('a', 'b')", assuming that the Foo * constructor has been defined in <code>scope</code>. * * @param scope The scope to search for the constructor and to evaluate * against * @param constructorName the name of the constructor to call * @param args the array of arguments for the constructor * @return the new object */ public final Scriptable newObject(Scriptable scope, String constructorName, Object[] args) { scope = ScriptableObject.getTopLevelScope(scope); Function ctor = ScriptRuntime.getExistingCtor(this, scope, constructorName); if (args == null) { args = ScriptRuntime.emptyArgs; } return ctor.construct(this, scope, args); }

kisstoto   07-03-29 01:13   // 행복한고니 자바스크립만 잘하면 뭐해여. 사람들이 왜 다구리하나 아직도 모르시겠나요... // 행복한고니 자바스크립만 잘하면 뭐해여. 사람들이 왜 다구리하나 아직도 모르시겠나요...

행복한고니   07-03-29 02:09   님의 의견은 고맙지만, 희한하게도 저는 kisstoto 님과 숨어지내리님의 아이피가 상당히 유사한 것에 눈길이 가네요. ^^ 님의 의견은 고맙지만, 희한하게도 저는 kisstoto 님과 숨어지내리님의 아이피가 상당히 유사한 것에 눈길이 가네요. ^^

숨어지내리   07-03-29 12:10   kisstoto 는 제 친구예요..ㅋㅋ ^^; 제가 그러지 말라고, 중간에 개입하지 말라고 충고 했습니다. ^^ 개의치 않아도 됩니다. ㅋ kisstoto 는 제 친구예요..ㅋㅋ ^^; 제가 그러지 말라고, 중간에 개입하지 말라고 충고 했습니다. ^^ 개의치 않아도 됩니다. ㅋ

똥파리   07-03-28 16:44   이런 역사적인 자리에 참석을 해보고 싶은 마음이 들어서 이렇게 용감하게 댓글답니다. 왠지 댓글다는 부분을 시간순으로 특정인을 중심으로 플레이를 해보면 감동적이겠다는 생각이 들었습니다. 아~ 만들어보고 싶네요 ^^ 모두 감동주셔서 고맙습니다.  예술같아요. 이런 역사적인 자리에 참석을 해보고 싶은 마음이 들어서 이렇게 용감하게 댓글답니다. 왠지 댓글다는 부분을 시간순으로 특정인을 중심으로 플레이를 해보면 감동적이겠다는 생각이 들었습니다. 아~ 만들어보고 싶네요 ^^ 모두 감동주셔서 고맙습니다. 예술같아요.

Java™엔시   07-03-29 00:01   스쿨최대의 토론이군요.ㄳ 스쿨최대의 토론이군요.ㄳ

Nal㏇™날나리코더   07-03-29 00:15   자 일단 휴식게이지 올리고 다시 만납시다. +,.+ 자 일단 휴식게이지 올리고 다시 만납시다. +,.+

송월동김모양   07-03-29 01:28   어이쿠....고생하셨습니다. 좋은 내용 보고 갑니다... 두분다 릴렉스 하시거 ^^ 어이쿠....고생하셨습니다. 좋은 내용 보고 갑니다... 두분다 릴렉스 하시거 ^^

불친절한코더씨   07-03-29 01:56   지나치고 말았는데 어느새 논쟁이... ;; 관심있게 관전? 하시는분들께 이해를 돕기위해 추천하고 싶은 문서가 있습니다.   http://www.crockford.com/javascript/ 보면 시작하는 첫번째 주제에 달린 링크중에 한글로 번역된 글도 있으니 살펴봐주세요. 그리고 "in javascript"에서 일어나는 상속에 대한 여러가지 이야기도 포함하고 다른문서도 있으니 도움이 되리라 봅니다. 또 참여 하시는 분들은 먼저 사용하는 용어 일치, 표준에 좀더 가깝게 지원하는 모질라 계열의 파이어폭스를 기준으로 예제를 첨부하는건 어떨까요? 지나치고 말았는데 어느새 논쟁이... ;; 관심있게 관전? 하시는분들께 이해를 돕기위해 추천하고 싶은 문서가 있습니다. http://www.crockford.com/javascript/ 보면 시작하는 첫번째 주제에 달린 링크중에 한글로 번역된 글도 있으니 살펴봐주세요. 그리고 "in javascript"에서 일어나는 상속에 대한 여러가지 이야기도 포함하고 다른문서도 있으니 도움이 되리라 봅니다. 또 참여 하시는 분들은 먼저 사용하는 용어 일치, 표준에 좀더 가깝게 지원하는 모질라 계열의 파이어폭스를 기준으로 예제를 첨부하는건 어떨까요?

행복한고니   07-03-29 02:24   제 예제는 언제나 FF 기준이었습니다. ^^ 사실, 맥 사용자라 IE 쓰는게 더 번거로워요. ( -_-)a 제 예제는 언제나 FF 기준이었습니다. ^^ 사실, 맥 사용자라 IE 쓰는게 더 번거로워요. ( -_-)a

Nal㏇™날나리코더   07-03-29 02:32   나도 맥에서 개발하고 싶음 ㅠㅠ;; 나도 맥에서 개발하고 싶음 ㅠㅠ;;

행복한고니   07-03-29 02:34   자바하신다고 하지 않으셨어요? 다른건 몰라도 J2EE 5 맥용이 없어서... 우리도 jsp쪽 연동작업할 때는 어쩔 수 없이 윈도우 쓰고 있어요. =_= 자바하신다고 하지 않으셨어요? 다른건 몰라도 J2EE 5 맥용이 없어서... 우리도 jsp쪽 연동작업할 때는 어쩔 수 없이 윈도우 쓰고 있어요. =_=

Nal㏇™날나리코더   07-03-29 02:40   훔..맥에 기본적으로 설치된게 jdk 1.5.x 라.. j2ee5 개발엔 문제가 없을듯한데여.... 요새 1.6.x java 6 플랫폼땜시 ㅎㅎ..근데 대부분 SI는 아직 1.4 플랫폼에서 개발되요 ㅎㅎ... 문제는 솔직히 java 단이 아니라 jsp 및 html단이죠.. 맥에서의 비주얼과 ie에서의 비주얼이 많이 차이가나니 ... 이쪽 고객들은 1픽셀로시비걸고 글씨체도 자신들 눈에 익지않은 글씨체 나오믄 바로 이슈발생이라서 ㅠㅠ 훔..맥에 기본적으로 설치된게 jdk 1.5.x 라.. j2ee5 개발엔 문제가 없을듯한데여.... 요새 1.6.x java 6 플랫폼땜시 ㅎㅎ..근데 대부분 SI는 아직 1.4 플랫폼에서 개발되요 ㅎㅎ... 문제는 솔직히 java 단이 아니라 jsp 및 html단이죠.. 맥에서의 비주얼과 ie에서의 비주얼이 많이 차이가나니 ... 이쪽 고객들은 1픽셀로시비걸고 글씨체도 자신들 눈에 익지않은 글씨체 나오믄 바로 이슈발생이라서 ㅠㅠ

행복한고니   07-03-29 02:50   그게 J2SE 예요. 덕분에 J2EE 기반으로 만들어진 프레임웍이 안돌아서 서비스 개발팀하고 같이 일하는데 지장이 많습니다. 1.4는 있다고 들었던 것 같아요. ^^; 그게 J2SE 예요. 덕분에 J2EE 기반으로 만들어진 프레임웍이 안돌아서 서비스 개발팀하고 같이 일하는데 지장이 많습니다. 1.4는 있다고 들었던 것 같아요. ^^;

Nal㏇™날나리코더   07-03-29 02:54   요새 새로 해보고싶은게 cocoa인데...하하.. 틈틈히 공부하려구요 ㅎㅎ.. 요새 새로 해보고싶은게 cocoa인데...하하.. 틈틈히 공부하려구요 ㅎㅎ..

행복한고니   07-03-29 02:58   저도 코코아 조금씩 공부하고 있습니다. 이제 겨우 화면 조금 만들어봤지만... Objective-C 이게 개념이 꽤 재밌어요. ^^ IDE 만들고 객체에 메소드 붙이고... 재밌더라구요. 예전에 애코에서 배포했던 Learnig Cocoa 한글판 PDF 있는데 드릴까요? 저도 코코아 조금씩 공부하고 있습니다. 이제 겨우 화면 조금 만들어봤지만... Objective-C 이게 개념이 꽤 재밌어요. ^^ IDE 만들고 객체에 메소드 붙이고... 재밌더라구요. 예전에 애코에서 배포했던 Learnig Cocoa 한글판 PDF 있는데 드릴까요?

Nal㏇™날나리코더   07-03-29 03:01   네 주세요 +,.+ valenny@naver.com 네 주세요 +,.+ valenny@naver.com

행복한고니   07-03-29 03:46   보내드렸습니다. ^^ 보내드렸습니다. ^^

불친절한코더씨   07-03-29 02:37   유명하다던 textmate 사용자인가요? 부럽... 유명하다던 textmate 사용자인가요? 부럽...

행복한고니   07-03-29 02:52   텍스트메이트가 상용이라서... T^T 그리고 요새는 모르겠는데 예전에 썼을때는 한글 문제가 있었던 것으로 기억합니다. IDE는 오직 Aptana! 취미 생활을 위해 Eclipse도 가끔 사용합니다. 간단한 텍스트 편집기는 Smultron 이용하고 있습니다. 텍스트메이트가 상용이라서... T^T 그리고 요새는 모르겠는데 예전에 썼을때는 한글 문제가 있었던 것으로 기억합니다. IDE는 오직 Aptana! 취미 생활을 위해 Eclipse도 가끔 사용합니다. 간단한 텍스트 편집기는 Smultron 이용하고 있습니다.

곰아야옹해봐   07-03-29 09:43   와우 대단하다;;ㄷㄷ 와우 대단하다;;ㄷㄷ

숨어지내리   07-03-29 11:45   ㅋㅋㅋ 역시 제가 보는 고니님의 본질을 맞는것 같습니다. ^^ 0. 자신의 주관을 사실인양 말한다. 제가 곧 증명할게 될것이니, 쭉 읽어 보십시요. 고니님 과 그외 추종자 분들 ^^ㅋㅋㅋ 일단 잠깐동안의 휴식기동안, 댓글을 많이들 다셨네요..^^ 많은 개발자분들이 보실꺼란 생각에 중간정도에 그만두려고 했는데, 누굴 가르치기 보단, 처음부터 끝까지 진실이 거짓에 가려지는건 용납할수 없습니다. 이글을 보시는분들의 유형은 전 이렇게 생각합니다. (제 주관입니다.) 65% : 고니님의 추종자분들 30% : 정말 그럴까? 라고 생각하시는 분들 5% : 아니다.라고 생각하시는분들.. ㅋㅋ rhino 소스까지 보니 제 생각이 일치한다는게 맞았던거 같습니다. --------------------------------------------------------------------------- public static Scriptable newObjectLiteral(Object[] propertyIds,                                           Object[] propertyValues,                                           Context cx, Scriptable scope) {     Scriptable object = cx.newObject(scope);     for (int i = 0, end = propertyIds.length; i != end; ++i) {         Object id = propertyIds[i];         Object value = propertyValues[i];         if (id instanceof String) {             ScriptableObject.putProperty(object, (String)id, value);         } else {             int index = ((Integer)id).intValue();             ScriptableObject.putProperty(object, index, value);         }     }     return object; } public final Scriptable newObject(Scriptable scope, String constructorName,                                   Object[] args) {     scope = ScriptableObject.getTopLevelScope(scope);     Function ctor = ScriptRuntime.getExistingCtor(this, scope,                                                   constructorName);     if (args == null) { args = ScriptRuntime.emptyArgs; }     Object a = ctor.construct(this , scope, args);     return ctor.construct(this, scope, args); } --------------------------------------------------------------------------- 이게 똑같다라고 보십니까? ㅋㅋ 코드가 다르다..ㅋㅋ 95% 5% 는 제 생각과 일치하시는 분들이라 생각합니다. 제가 철학자도 아니고, 본질까지 말할줄은 몰랐습니다. ㅋㅋ 서론이 길었습니다. 얼마전의 개콘의 개그 두뇌트레이닝을 보고 너무 재미있었습니다. 신선하고요..ㅋㅋㅋ( 따라해봤습니다.ㅋ) 결론부터 말하자면, new Object() !=== {} 라는 것입니다. !=== 왜 === 세개를 했는지는 본질을 말하기 위해서 그렇게 표현합니다. 1. 아직도 고니님의 주장이 그렇습니까? 아니오라고 하는 분들은 개발자의 길에 '최상급'을 달리고 계십니다.ㅋㅋ 2. 저 코드는 {} 는 본질의 instance()를 재가공한다. new Object() 는 본질의 instance() 를 반환한다. 아직도 고니님의 생각에 동의하십니까? ㅋㅋ 아니오 라고 대답하시는 분들은 개발자의 '고급'을 달리고 계십니다. ㅋㅋ 3. rhino 의 newObject 메서드 중 ctor.construct(this, scope, args); 보시고, Object a = ctor.construct(this , scope, args); return a; 아직도 고니님의 생각에 동의하십니까? ㅋㅋ 아니오 라고 대답하시는 분들은 개발자의 초급을 달리고 계십니다. ㅋㅋ 4. 그럼 javascript 로 표현하겠습니다. object = new Object(); function a() {     var object = new Object();     var tmp;     for(var i = 0; i < arguments[i] ; ++i){         tmp = arguments[i].split(':');         object[tmp[0]] = tmp[1];     }     return object; }; var xx  = a(); alert(xx.__proto__.__proto__);        // null alert(object.__proto__.__proto__);  // null alert(object.__proto__ === xx.__proto__);    // Object 는 같다. alert(object === xx);    // false 아직도 고니님의 생각에 동의하십니까? 아니오 라고 생각하시는 분들은 개발자의 길을 걸으셔도 됩니다. 예 라고 하시는분들은 다른 직업을 찾아 보시기 바랍니다. ^^ 결론 : rhino 소스에서도 나와있듯이 constuctor 를 실행하는 것이 new Object() 의 본질이고, {} 은 그 실행되어진 본질을 재가공하는것이 본질입니다. 따라서 new Object() !=== {} 는 성립된다고 할수 있습니다. 제가 결론부터 말한 고니님의 본질 '0. 자신의 주관을 사실인양 말한다.' 도 증명된거 같군요. 사전적인 의미에서 왜 rhino 에서도 equivalent 으로 되어 있는지 설명이 되어집니다. e·quiv·a·lent〔〕〔L 「같은 가치의」의 뜻에서〕 a. 1 동등한, 같은 가치[양]의;<말·표현이> 같은 뜻의                             ^ 양과 질은 엄연히 다른것입니다. new Object().constructor === Object 를 비교하는것이 어불성설이라는 말이 그것과 같습니다. 만약 Object 라는 본질이 같은것이라면,   본질(本質) true[intrinsic] nature;essence;substance 으로 표기하여, 다른분들에게 혼돈이 없게 하였을것으로 생각됩니다. {} 은 이미 constructor 가 실행되어진 객체를 재가공하는 역할을 하고 있는것입니다. 이로써 제가 증명해야 할게 더 남았나요? 아~ Object 는 Function 의 instance 이다. ㅋ 불친절한 코더님이 제공한 주소 보시고, http://javascript.crockford.com/prototypal.html function object(o) {     function F() {}     F.prototype = o;     return new F(); } 다시 잘 생각하시고 보세요.!!! 고니님 ^^ 전 한번은 읽어 봤으니깐요. (다 해석은 못해지만 말입니다. 주관이 섞여서..ㅋㅋㅋ) 고로 논쟁거리 1. new Object() === {} 가 같다? 2. Object 가 {} 으로 만들어진다? 3. constructor 의 비교로 객체가 똑같다고 말할수 있다? 4. Object 는 Function 의 instance 이다? 모두가 고니님의 틀린 주관으로 사실인양 말하는 전제 0 이  밝혀지게 된것입니다. ㅡㅡ;;;;; //======================================= 고로, 고니님이 주장하는 1,2 의 항목이 거짓입니다. 그러면, 여태 주장한 모든 것은 '주관,고집' 으로 보이는 것입니다. ---------------------------------------------------------------------------------  검증되지 않은 지식을 가지고 있는 것도 아주 싫어합니다. --------------------------------------------------------------------------------- 따라서, 고니님은 고니님을 아주 싫어하는 것입니다. ㅡㅡ;;;; 이런게 논리고 , 응용입니다. 고니님.. //======================================= 이렇게 되는것이고.. //======================================= -------------------------------------------------------------------------------------- 말귀도 못알아먹는 사람과는 어머니께서 친하게 지내지 말라더라군요. -------------------------------------------------------------------------------------- 이젠 어머님의 말씀을 따라야 할것 같습니다. ㅠㅠ //======================================= 이렇게 된것이니.. 누굴 탓하겠습니까? 이기기 좋아하고, 진다고 생각하면, 이상한 논리와 원소스까지 들이대면서 추종자분들과 바락바락 우기는 고니님... 참 까탈스럽습니다.. ps. 고니님 책은 쓰시지 마세요.!! 부탁드립니다. 다른분들에게 주관을 설파하시지는 마세요. ^^ ㅋㅋㅋ 역시 제가 보는 고니님의 본질을 맞는것 같습니다. ^^ 0. 자신의 주관을 사실인양 말한다. 제가 곧 증명할게 될것이니, 쭉 읽어 보십시요. 고니님 과 그외 추종자 분들 ^^ㅋㅋㅋ 일단 잠깐동안의 휴식기동안, 댓글을 많이들 다셨네요..^^ 많은 개발자분들이 보실꺼란 생각에 중간정도에 그만두려고 했는데, 누굴 가르치기 보단, 처음부터 끝까지 진실이 거짓에 가려지는건 용납할수 없습니다. 이글을 보시는분들의 유형은 전 이렇게 생각합니다. (제 주관입니다.) 65% : 고니님의 추종자분들 30% : 정말 그럴까? 라고 생각하시는 분들 5% : 아니다.라고 생각하시는분들.. ㅋㅋ rhino 소스까지 보니 제 생각이 일치한다는게 맞았던거 같습니다. --------------------------------------------------------------------------- public static Scriptable newObjectLiteral(Object[] propertyIds, Object[] propertyValues, Context cx, Scriptable scope) { Scriptable object = cx.newObject(scope); for (int i = 0, end = propertyIds.length; i != end; ++i) { Object id = propertyIds[i]; Object value = propertyValues[i]; if (id instanceof String) { ScriptableObject.putProperty(object, (String)id, value); } else { int index = ((Integer)id).intValue(); ScriptableObject.putProperty(object, index, value); } } return object; } public final Scriptable newObject(Scriptable scope, String constructorName, Object[] args) { scope = ScriptableObject.getTopLevelScope(scope); Function ctor = ScriptRuntime.getExistingCtor(this, scope, constructorName); if (args == null) { args = ScriptRuntime.emptyArgs; } Object a = ctor.construct(this , scope, args); return ctor.construct(this, scope, args); } --------------------------------------------------------------------------- 이게 똑같다라고 보십니까? ㅋㅋ 코드가 다르다..ㅋㅋ 95% 5% 는 제 생각과 일치하시는 분들이라 생각합니다. 제가 철학자도 아니고, 본질까지 말할줄은 몰랐습니다. ㅋㅋ 서론이 길었습니다. 얼마전의 개콘의 개그 두뇌트레이닝을 보고 너무 재미있었습니다. 신선하고요..ㅋㅋㅋ( 따라해봤습니다.ㅋ) 결론부터 말하자면, new Object() !=== {} 라는 것입니다. !=== 왜 === 세개를 했는지는 본질을 말하기 위해서 그렇게 표현합니다. 1. 아직도 고니님의 주장이 그렇습니까? 아니오라고 하는 분들은 개발자의 길에 '최상급'을 달리고 계십니다.ㅋㅋ 2. 저 코드는 {} 는 본질의 instance()를 재가공한다. new Object() 는 본질의 instance() 를 반환한다. 아직도 고니님의 생각에 동의하십니까? ㅋㅋ 아니오 라고 대답하시는 분들은 개발자의 '고급'을 달리고 계십니다. ㅋㅋ 3. rhino 의 newObject 메서드 중 ctor.construct(this, scope, args); 보시고, Object a = ctor.construct(this , scope, args); return a; 아직도 고니님의 생각에 동의하십니까? ㅋㅋ 아니오 라고 대답하시는 분들은 개발자의 초급을 달리고 계십니다. ㅋㅋ 4. 그럼 javascript 로 표현하겠습니다. object = new Object(); function a() { var object = new Object(); var tmp; for(var i = 0; i < arguments[i] ; ++i){ tmp = arguments[i].split(':'); object[tmp[0]] = tmp[1]; } return object; }; var xx = a(); alert(xx.__proto__.__proto__); // null alert(object.__proto__.__proto__); // null alert(object.__proto__ === xx.__proto__); // Object 는 같다. alert(object === xx); // false 아직도 고니님의 생각에 동의하십니까? 아니오 라고 생각하시는 분들은 개발자의 길을 걸으셔도 됩니다. 예 라고 하시는분들은 다른 직업을 찾아 보시기 바랍니다. ^^ 결론 : rhino 소스에서도 나와있듯이 constuctor 를 실행하는 것이 new Object() 의 본질이고, {} 은 그 실행되어진 본질을 재가공하는것이 본질입니다. 따라서 new Object() !=== {} 는 성립된다고 할수 있습니다. 제가 결론부터 말한 고니님의 본질 '0. 자신의 주관을 사실인양 말한다.' 도 증명된거 같군요. 사전적인 의미에서 왜 rhino 에서도 equivalent 으로 되어 있는지 설명이 되어집니다. e·quiv·a·lent〔〕〔L 「같은 가치의」의 뜻에서〕 a. 1 동등한, 같은 가치[양]의;<말·표현이> 같은 뜻의 ^ 양과 질은 엄연히 다른것입니다. new Object().constructor === Object 를 비교하는것이 어불성설이라는 말이 그것과 같습니다. 만약 Object 라는 본질이 같은것이라면, 본질(本質) true[intrinsic] nature;essence;substance 으로 표기하여, 다른분들에게 혼돈이 없게 하였을것으로 생각됩니다. {} 은 이미 constructor 가 실행되어진 객체를 재가공하는 역할을 하고 있는것입니다. 이로써 제가 증명해야 할게 더 남았나요? 아~ Object 는 Function 의 instance 이다. ㅋ 불친절한 코더님이 제공한 주소 보시고, http://javascript.crockford.com/prototypal.html function object(o) { function F() {} F.prototype = o; return new F(); } 다시 잘 생각하시고 보세요.!!! 고니님 ^^ 전 한번은 읽어 봤으니깐요. (다 해석은 못해지만 말입니다. 주관이 섞여서..ㅋㅋㅋ) 고로 논쟁거리 1. new Object() === {} 가 같다? 2. Object 가 {} 으로 만들어진다? 3. constructor 의 비교로 객체가 똑같다고 말할수 있다? 4. Object 는 Function 의 instance 이다? 모두가 고니님의 틀린 주관으로 사실인양 말하는 전제 0 이 밝혀지게 된것입니다. ㅡㅡ;;;;; //======================================= 고로, 고니님이 주장하는 1,2 의 항목이 거짓입니다. 그러면, 여태 주장한 모든 것은 '주관,고집' 으로 보이는 것입니다. --------------------------------------------------------------------------------- 검증되지 않은 지식을 가지고 있는 것도 아주 싫어합니다. --------------------------------------------------------------------------------- 따라서, 고니님은 고니님을 아주 싫어하는 것입니다. ㅡㅡ;;;; 이런게 논리고 , 응용입니다. 고니님.. //======================================= 이렇게 되는것이고.. //======================================= -------------------------------------------------------------------------------------- 말귀도 못알아먹는 사람과는 어머니께서 친하게 지내지 말라더라군요. -------------------------------------------------------------------------------------- 이젠 어머님의 말씀을 따라야 할것 같습니다. ㅠㅠ //======================================= 이렇게 된것이니.. 누굴 탓하겠습니까? 이기기 좋아하고, 진다고 생각하면, 이상한 논리와 원소스까지 들이대면서 추종자분들과 바락바락 우기는 고니님... 참 까탈스럽습니다.. ps. 고니님 책은 쓰시지 마세요.!! 부탁드립니다. 다른분들에게 주관을 설파하시지는 마세요. ^^

행복한고니   07-03-29 12:27   자신의 논리가 바껴있다는 것을 이제 인정하실 때도 됐는데... ^^ ________________________________________________ 제가 보는 관점은 Object - {}                                   - Array 와 같이 상속처럼 구현되어져 있고 , {} 은 연관배열(배열의 형태는 필드명에 의한 문자열 인덱스 배열(associative array; 혹은 연상배열) 로 구성된다는 겁니다. ________________________________________________ {} 는 분명 Object 를 implements 했을뿐이고, 그렇게 보이는것입니다. ________________________________________________ 물론 Array 또한 Object 를 implements 한것이고요.. ________________________________________________ 이렇다면서요? ^^ 계속 주장해보세요. ㅎㅎ 아... 자신의 주장에 동의하는 사람은 "진짜 개발자"이고, 제 주장에 동의하는 사람은 "추종자"이군요. 아... 그리고 왜 생성자가 같으면 같은 객체타입인지를 밝히는데는 고등학교 정규과정만 밟았어도 나옵니다. 이른바, 3단 논법이죠. 생성자가 객체타입을 결정한다. A와 B의 생성자는 같다. 따라서, A와 B의 객체타입은 같다. 하지만 위 명제를 통해 다음과 같은 논리는 절대 나올 수가 없습니다. A와 B의 생성자가 같다. 따라서, A와 B는 같다.(identity) 또한 다음과 같은 논리도 결코 나올 수가 없죠. A와 B의 생성자의 생성자가 같다. 따라서, A와 B는 같다. 저 같은 하수의 말이라 아직도 인정을 못하시겠다면 님께서 인정하실만한 고수분께 부탁드려서 중재를 부탁드려볼까요? ^^ ㅎㅎ 그래도 시간을 들였으니 확실히 아시고 가셔야죠? P.S// 프로그래밍 언어의 용어를 해석하면서 equivalent 를 등량(等量)이라고 해석하는 사람은 처음 봤습니다. 등가(等價)로 볼텐데 말이죠. 자신의 논리가 바껴있다는 것을 이제 인정하실 때도 됐는데... ^^ ________________________________________________ 제가 보는 관점은 Object - {} - Array 와 같이 상속처럼 구현되어져 있고 , {} 은 연관배열(배열의 형태는 필드명에 의한 문자열 인덱스 배열(associative array; 혹은 연상배열) 로 구성된다는 겁니다. ________________________________________________ {} 는 분명 Object 를 implements 했을뿐이고, 그렇게 보이는것입니다. ________________________________________________ 물론 Array 또한 Object 를 implements 한것이고요.. ________________________________________________ 이렇다면서요? ^^ 계속 주장해보세요. ㅎㅎ 아... 자신의 주장에 동의하는 사람은 "진짜 개발자"이고, 제 주장에 동의하는 사람은 "추종자"이군요. 아... 그리고 왜 생성자가 같으면 같은 객체타입인지를 밝히는데는 고등학교 정규과정만 밟았어도 나옵니다. 이른바, 3단 논법이죠. 생성자가 객체타입을 결정한다. A와 B의 생성자는 같다. 따라서, A와 B의 객체타입은 같다. 하지만 위 명제를 통해 다음과 같은 논리는 절대 나올 수가 없습니다. A와 B의 생성자가 같다. 따라서, A와 B는 같다.(identity) 또한 다음과 같은 논리도 결코 나올 수가 없죠. A와 B의 생성자의 생성자가 같다. 따라서, A와 B는 같다. 저 같은 하수의 말이라 아직도 인정을 못하시겠다면 님께서 인정하실만한 고수분께 부탁드려서 중재를 부탁드려볼까요? ^^ ㅎㅎ 그래도 시간을 들였으니 확실히 아시고 가셔야죠? P.S// 프로그래밍 언어의 용어를 해석하면서 equivalent 를 등량(等量)이라고 해석하는 사람은 처음 봤습니다. 등가(等價)로 볼텐데 말이죠.

comefeel   07-03-29 13:33   논쟁은 끝났으니깐 이글 이외에 달지마세여 . 논쟁은 끝났으니깐 이글 이외에 달지마세여 .

발광머리앤   07-03-29 12:13   너무 길어서 "전혀" 읽지 않고 답글 올립니다 ㅋㅋ new Object() 와 {} 가 같냐 틀리냐 문제인가요?;; 두개는 다릅니다~ 끝 ㅋㅋ new Object() 했을때랑 {} 했을때랑 다른점을 같은 구현 코드로 한쪽만 에러내는 방법이 있는데 위에 그 예가 나왔나 모르겠네요; 찾기도 귀찮고 오래전에 본거라; C에서 링크드 리스트 하나로 큐, 스택, 힙 등을 구현하듯이.. http://en.wikipedia.org/wiki/Prototype-based_programming JS는 prototype based 객체지향 언어입니다. 물론 객체의 모든 성질을 충족하지 못하고 부족한 부분이 있습니다만; 위로 올라가면 두놈은 같은 형질의 놈입니다만 상속된 실제 구현체에서는 좀 다릅니다.. JS의 Object가 named array of properties and methods 라는 견해도 있는데 음.. 전 반반입니다; 논리적으로 new Object() 와 {}가 같은 개념일진 몰라도 실제 사용해보면 약간 차이가 나고.. {} 는 Object literals 가 맞고요 여튼 헛소리만 찍 하고 이만;; 너무 길어서 "전혀" 읽지 않고 답글 올립니다 ㅋㅋ new Object() 와 {} 가 같냐 틀리냐 문제인가요?;; 두개는 다릅니다~ 끝 ㅋㅋ new Object() 했을때랑 {} 했을때랑 다른점을 같은 구현 코드로 한쪽만 에러내는 방법이 있는데 위에 그 예가 나왔나 모르겠네요; 찾기도 귀찮고 오래전에 본거라; C에서 링크드 리스트 하나로 큐, 스택, 힙 등을 구현하듯이.. http://en.wikipedia.org/wiki/Prototype-based_programming JS는 prototype based 객체지향 언어입니다. 물론 객체의 모든 성질을 충족하지 못하고 부족한 부분이 있습니다만; 위로 올라가면 두놈은 같은 형질의 놈입니다만 상속된 실제 구현체에서는 좀 다릅니다.. JS의 Object가 named array of properties and methods 라는 견해도 있는데 음.. 전 반반입니다; 논리적으로 new Object() 와 {}가 같은 개념일진 몰라도 실제 사용해보면 약간 차이가 나고.. {} 는 Object literals 가 맞고요 여튼 헛소리만 찍 하고 이만;;

Lanky   07-03-29 13:22   어느것이 진실이죠... 어느것이 진실이죠...

무소레즈   07-03-29 22:38   숨어지내리님의 글중에... 논쟁거리라는 아래 내용이 첨부되어 있기에 그에 대한 제 답변도 올려 봅니다. --------------------------------------- 1. new Object() === {} 가 같다? 2. Object 가 {} 으로 만들어진다? 3. constructor 의 비교로 객체가 똑같다고 말할수 있다? 4. Object 는 Function 의 instance 이다? --------------------------------------- 1. new Object() === {} 가 같다? 답변 1. 엄밀하게 다릅니다.     ( new Object() === {} )  의 결과는 false 입니다.     하지만 함수 객체타입은 같기에  instance 를 비교하면 true 입니다.     왜냐하면 같은 Object 함수의 객체타입으로 생성되기 때문입니다.     어떤 함수든 new 통하여 새로운 instance 개체를 생성하면     어떤 instance 개체든 Object 함수 객체타입의 instance 를 갖습니다.     예를 들어         today = new Date();         today 라는 instance 개체는         Date 함수객체타입의 instance 이기도 하지만         Object 함수 객체타입의 instance 이기도 합니다.     또한 사용자 정의 함수를 통하여 새로운 instance 개체를 생성해도 마찬가지입니다.         function funcName() {         }         fn = new funcName();         fn 이라는 instance 개체는         funcName 함수객체타입의 instance 이기도 하지만         Object 함수 객체타입의 instance 이기도 합니다.         fn 은 독립적인 instance 개체로서         funcName 이라는 함수객체에서 정의된 구조(초기환경설정)의 instance 을 가졌다는 것이지요.         만약 funcName 함수로 또다른 instance 개체를 생성한다면         fn2 = new funcName();         fn2 은 fn 과는 서로다른  instance 개체이지만         funcName 이라는 함수명으로 정의된 구조를 가진 같은 instance 를 가집니다.         fn1 과 fn2 는 같은 instance 를 가지고 있지만 서로 다른 개체입니다.     (new Object) 와  {} 에의해 생성된 각각의 instance 객체변수로 비교하자면         x1=new Object         x2=new Object         y1={};         y2={};         (x1 === x2);         (y1 === y2)         (x1 === y1);         (x2 === y2);     모두 false 입니다.  생성된 instance 개체가 서로 독립적이기 때문이지요.     하지만  instanceof 연산자를 이용하여 비교해보면 모두 같은 instance 를 가지고 있습니다.     Object 함수객체 타입은  ( Object.prototype.constructor ) 로 알아낼수 있습니다.       결과는 :  function Object() { [native code] }     funcName 함수객체 타입은  ( funcName.prototype.constructor ) 로 알아낼수 있습니다.       결과는 : function funcName() { }     (new Object ) 와 {} 는 미리 정의된 Object 함수 객체를 통하여     서로다른 새로운 instance 개체들을 생성합니다.     사용자 정의 함수에서 처럼  funcName 이 없기때문에     Object 함수 객체타입의 instance 만을 갖게 되는 것입니다.     ★ 그렇다고 (new Object) 와 {} 가 Object 함수객체 내부에서 주어진 정의가 완전히 같은가?     그렇지 않습니다.     {} 는 Object initializer (개체 초기화 지정자) 라고 불리우며,     Object initializer 라 불리우는 {} 를 다른 함수의 내부에서 사용시     Object initializer 를 호출할때 마다, {} 에의 정의된  속성과 그에 할당된 표현식이나 값을     매번 다시 해석(interpret) 한다는 것이 (new Object) 와 다릅니다.     함수내부에서 개체 초기화 지정자인 {} 를 정의하고     그 함수를  호출하면 {} 에의해 정의된 속성과 그 값을 다시 해석하여     매번 초기화 시킨다는것입니다.         function funcName (cond) {                 A=3;                 B={ A:5 };                 C=new Object;                 Object.prototype.A=7;                 if(cond==1) return B.A;                 else if( cond==2) return C.A;                 else  return A;         }         A1=funcName(0);         B1=funcName(1);         C1=funcName(2);         A2=funcName(0);         B2=funcName(1);         C2=funcName(2);         A1 과 A2 는 메모리에 이미 저장된 "3" 이란 값을 반환 받습니다.         C1 과 C2 도 메모리에 이미 저장된 "7" 이란 값을 반환 받습니다.         B1 과 B2 는 각각 호출시 초기화 지정자를 재 해석하여 메모리에 다시 올려 놓고,         그 후에 "5" 라는 값을 반환합니다.         B 는  초기화 지정자 {}로 할당 받았기 때문에         매번 함수를 호출 할때마다  B 의 속성과 값을 재 해석하여 메모리에 재 저장합니다.         즉, 함수를 호출할때마다 매번 다시 초기화 시킨다는 말입니다.         만약 함수 외부에서 초기화 지정자를 사용했다면         var G={ A: 9 };         G.A 를 호출할때 이미 초기화되어 메모리에 저장되어 있는 "9" 라는 값을 불러오게 됩니다.         다른 곳에서 G.A 를 호출해도 역시 이미 저장되어 있는 값 "9"를 반환합니다.         함수 내부에서 처럼 재 해석하여 재 초기화 시키는 것이 아닙니다.         C1 과 C2 를 호출하면 이미 메모리에 저정되어 있는  "7" 이라는 값을 반환합니다.         B1 과 B2 처럼 호출할때마다 재 초기화 시키는 것이 아닙니다.         그렇게 (new Object ) 와 {} 는 다릅니다. 2. Object 가 {} 으로 만들어진다? 답변 2.     {} 를 호출하면 내부에서 새로운 (new Object) 를 생성하여 instance 개체를 반환한다고 알고 있습니다. 3. constructor 의 비교로 객체가 똑같다고 말할수 있다? 답변 3.     (객체.constructor) 의 사용은 생성자가 어떤 객체타입을 가지고 있는지 참조할수 있도록     미리 정의되어 있는 Object 의 prototype 일뿐입니다.     프로그램의 처리 로직에따라 객체의 속성으로써 prototype 정의는 언제든 변경 가능하며     변경된 결과를 처리 조건에따라 필요할때 마다 활용할 수 있습니다.     (개체.constructor) 는      개체를 새로 생성했을때 그 개체가     어떤 객체 타입을 가진 생성자 함수로부터 생성된 개체인지를 참조할 수 있도록     Javascript 에서 미리 정의해둔 하나의 속성 일뿐입니다.     변경 불가한 상수가 아니란 것이지요.     프로그램 처리의 상황에따라 그 값을 변경하며, 참조하여 활용할 수 있습니다.     "constructor 의 비교로 객체가 똑같다고 말할수 있습니다."     에대해서는 그럴수도 있고 아닐수도 있겠지요.     프로그램의 처리 상황에따라 그 속성을 주어진대로 활용하거나, 변경하여 사용하거나     아니면 사용하지 않거나..     엿을 파는 엿장수 맘 아니겠습니까?     엿장수 맘대로 사용했을때 문제가 발생할 여지가 있다면야 그렇게 사용해서는 안되겠지요.     어느 분이든...  어떤 경우에 문제가 생기는지 알려주시면     저도 다음부터는 유의하여 사용해 보겠습니다. 4. Object 는 Function 의 instance 이다? 답변 4.     이미 정의되어 있는 Object 는 Function 함수 객체로부터 생성된 함수 객체이기때문에         Function 함수 객체타입의 instance 를 갖습니다.         또한 동시에 new 를 통하여 생성되기때문에 Object 객체타입의 instance  를 갖기도 합니다. 숨어지내리님의 글중에... 논쟁거리라는 아래 내용이 첨부되어 있기에 그에 대한 제 답변도 올려 봅니다. --------------------------------------- 1. new Object() === {} 가 같다? 2. Object 가 {} 으로 만들어진다? 3. constructor 의 비교로 객체가 똑같다고 말할수 있다? 4. Object 는 Function 의 instance 이다? --------------------------------------- 1. new Object() === {} 가 같다? 답변 1. 엄밀하게 다릅니다. ( new Object() === {} ) 의 결과는 false 입니다. 하지만 함수 객체타입은 같기에 instance 를 비교하면 true 입니다. 왜냐하면 같은 Object 함수의 객체타입으로 생성되기 때문입니다. 어떤 함수든 new 통하여 새로운 instance 개체를 생성하면 어떤 instance 개체든 Object 함수 객체타입의 instance 를 갖습니다. 예를 들어 today = new Date(); today 라는 instance 개체는 Date 함수객체타입의 instance 이기도 하지만 Object 함수 객체타입의 instance 이기도 합니다. 또한 사용자 정의 함수를 통하여 새로운 instance 개체를 생성해도 마찬가지입니다. function funcName() { } fn = new funcName(); fn 이라는 instance 개체는 funcName 함수객체타입의 instance 이기도 하지만 Object 함수 객체타입의 instance 이기도 합니다. fn 은 독립적인 instance 개체로서 funcName 이라는 함수객체에서 정의된 구조(초기환경설정)의 instance 을 가졌다는 것이지요. 만약 funcName 함수로 또다른 instance 개체를 생성한다면 fn2 = new funcName(); fn2 은 fn 과는 서로다른 instance 개체이지만 funcName 이라는 함수명으로 정의된 구조를 가진 같은 instance 를 가집니다. fn1 과 fn2 는 같은 instance 를 가지고 있지만 서로 다른 개체입니다. (new Object) 와 {} 에의해 생성된 각각의 instance 객체변수로 비교하자면 x1=new Object x2=new Object y1={}; y2={}; (x1 === x2); (y1 === y2) (x1 === y1); (x2 === y2); 모두 false 입니다. 생성된 instance 개체가 서로 독립적이기 때문이지요. 하지만 instanceof 연산자를 이용하여 비교해보면 모두 같은 instance 를 가지고 있습니다. Object 함수객체 타입은 ( Object.prototype.constructor ) 로 알아낼수 있습니다. 결과는 : function Object() { [native code] } funcName 함수객체 타입은 ( funcName.prototype.constructor ) 로 알아낼수 있습니다. 결과는 : function funcName() { } (new Object ) 와 {} 는 미리 정의된 Object 함수 객체를 통하여 서로다른 새로운 instance 개체들을 생성합니다. 사용자 정의 함수에서 처럼 funcName 이 없기때문에 Object 함수 객체타입의 instance 만을 갖게 되는 것입니다. ★ 그렇다고 (new Object) 와 {} 가 Object 함수객체 내부에서 주어진 정의가 완전히 같은가? 그렇지 않습니다. {} 는 Object initializer (개체 초기화 지정자) 라고 불리우며, Object initializer 라 불리우는 {} 를 다른 함수의 내부에서 사용시 Object initializer 를 호출할때 마다, {} 에의 정의된 속성과 그에 할당된 표현식이나 값을 매번 다시 해석(interpret) 한다는 것이 (new Object) 와 다릅니다. 함수내부에서 개체 초기화 지정자인 {} 를 정의하고 그 함수를 호출하면 {} 에의해 정의된 속성과 그 값을 다시 해석하여 매번 초기화 시킨다는것입니다. function funcName (cond) { A=3; B={ A:5 }; C=new Object; Object.prototype.A=7; if(cond==1) return B.A; else if( cond==2) return C.A; else return A; } A1=funcName(0); B1=funcName(1); C1=funcName(2); A2=funcName(0); B2=funcName(1); C2=funcName(2); A1 과 A2 는 메모리에 이미 저장된 "3" 이란 값을 반환 받습니다. C1 과 C2 도 메모리에 이미 저장된 "7" 이란 값을 반환 받습니다. B1 과 B2 는 각각 호출시 초기화 지정자를 재 해석하여 메모리에 다시 올려 놓고, 그 후에 "5" 라는 값을 반환합니다. B 는 초기화 지정자 {}로 할당 받았기 때문에 매번 함수를 호출 할때마다 B 의 속성과 값을 재 해석하여 메모리에 재 저장합니다. 즉, 함수를 호출할때마다 매번 다시 초기화 시킨다는 말입니다. 만약 함수 외부에서 초기화 지정자를 사용했다면 var G={ A: 9 }; G.A 를 호출할때 이미 초기화되어 메모리에 저장되어 있는 "9" 라는 값을 불러오게 됩니다. 다른 곳에서 G.A 를 호출해도 역시 이미 저장되어 있는 값 "9"를 반환합니다. 함수 내부에서 처럼 재 해석하여 재 초기화 시키는 것이 아닙니다. C1 과 C2 를 호출하면 이미 메모리에 저정되어 있는 "7" 이라는 값을 반환합니다. B1 과 B2 처럼 호출할때마다 재 초기화 시키는 것이 아닙니다. 그렇게 (new Object ) 와 {} 는 다릅니다. 2. Object 가 {} 으로 만들어진다? 답변 2. {} 를 호출하면 내부에서 새로운 (new Object) 를 생성하여 instance 개체를 반환한다고 알고 있습니다. 3. constructor 의 비교로 객체가 똑같다고 말할수 있다? 답변 3. (객체.constructor) 의 사용은 생성자가 어떤 객체타입을 가지고 있는지 참조할수 있도록 미리 정의되어 있는 Object 의 prototype 일뿐입니다. 프로그램의 처리 로직에따라 객체의 속성으로써 prototype 정의는 언제든 변경 가능하며 변경된 결과를 처리 조건에따라 필요할때 마다 활용할 수 있습니다. (개체.constructor) 는 개체를 새로 생성했을때 그 개체가 어떤 객체 타입을 가진 생성자 함수로부터 생성된 개체인지를 참조할 수 있도록 Javascript 에서 미리 정의해둔 하나의 속성 일뿐입니다. 변경 불가한 상수가 아니란 것이지요. 프로그램 처리의 상황에따라 그 값을 변경하며, 참조하여 활용할 수 있습니다. "constructor 의 비교로 객체가 똑같다고 말할수 있습니다." 에대해서는 그럴수도 있고 아닐수도 있겠지요. 프로그램의 처리 상황에따라 그 속성을 주어진대로 활용하거나, 변경하여 사용하거나 아니면 사용하지 않거나.. 엿을 파는 엿장수 맘 아니겠습니까? 엿장수 맘대로 사용했을때 문제가 발생할 여지가 있다면야 그렇게 사용해서는 안되겠지요. 어느 분이든... 어떤 경우에 문제가 생기는지 알려주시면 저도 다음부터는 유의하여 사용해 보겠습니다. 4. Object 는 Function 의 instance 이다? 답변 4. 이미 정의되어 있는 Object 는 Function 함수 객체로부터 생성된 함수 객체이기때문에 Function 함수 객체타입의 instance 를 갖습니다. 또한 동시에 new 를 통하여 생성되기때문에 Object 객체타입의 instance 를 갖기도 합니다.

nmccm   07-03-30 09:38   잘보고갑니다.. 고맙습니다. 잘보고갑니다.. 고맙습니다.

낭망백수   07-03-30 19:33   무소레즈 // 님 이거 스크랩해가도 되겠습니까? 혹은 님 블로그에 올려두시면, 트랙백이라도 걸죠. 블로그 주소 보내주시면 감사~~ mulriver@gmail.com 꾸벅~! 무소레즈 // 님 이거 스크랩해가도 되겠습니까? 혹은 님 블로그에 올려두시면, 트랙백이라도 걸죠. 블로그 주소 보내주시면 감사~~ mulriver@gmail.com 꾸벅~!

무소레즈   07-03-30 21:49   네.. 어떤 방법으로든  가져 가셔서 해당 부분에대해 잘못된 점은 수정하시고, 추가할 부분은 추가하시고, 지울 부분은 지우시면서 부분적으로나마, 보다 완성된 지식으로 재가공 되어지길 바랄뿐 입니다. 아..참..용어의 표현에 있어서도 마찬가지입니다.

출처 - PHP SCHOOL

invalid-file

저자: Brad Neuberg, 한동훈 역

여기서는 AJAX 응용 프로그램에 즐겨찾기와 뒤로 이동을 지원하는 오픈 소스 자바스크립트 라이브러리를 소개할 것이다. 이 글을 마지막까지 보게된다면 구글맵스나 지메일과 같은 곳들조차 제대로 지원하지 못했던 웹 사이트에서의 즐겨찾기, 앞으로 이동, 뒤로 이동과 같은 AJAX의 문제들을 해결할 수 있게 될 것이다.

"AJAX: 즐겨찾기와 뒤로 이동을 다루는 방법"에서는 ^[1]에이잭스(AJAX) 응용 프로그램들이 현재 당면하고 있는 즐겨찾기, 뒤로 이동과 같은 중요한 문제들을 설명하고, 이 문제를 해결하기 위한 오픈 소스 프레임워크인 RSH(Really Simple History) 라이브러리를 소개하고, 실제 예제들을 몇 가지 소개할 것이다.

(^[1]역주: 영어사전에서 AJAX는 에이잭스로 소개되며, 그리스의 신화의 아이아스나 오딧세이의 아이아스를 의미한다. sys-con의 AJAX & Rich Internet Applications 프레젠테이션에서도 그 발음을 확인할 수 있다. 네덜란드 축구팀의 이름을 딴 아약스, 또는 아작스 등으로 불리기도 한다. 한편, 세제 제조회사인 Ajax Industries는 "에이잭스社"로 옮긴다.)

여기서 소개할 프레임워크의 주요 부분은 두 개로 나뉘어진다. 첫째는 클라이언트의 정보를 갖고 있는 임시 세션 캐시를 사용하기 위해 숨겨진 HTML 폼을 사용한다. 이 캐시는 어떤 지점으로 이동하거나 페이지를 떠나는 경우에도 사용할 수 있다. 둘째는 A 태그와 숨겨진 iframe을 사용해서 브라우저 히스토리를 가로챈 다음 브라우저 히스토리 이벤트를 기록하고, 뒤로 이동과 앞으로 이동 버튼에 연결한다. 이 두 가지 기능은 모두 개발시에 쉽게 이용할 수 있도록 간단한 자바스크립트 라이브러리로 되어있다.

문제

즐겨찾기와 뒤로 이동은 여러 페이지로 구성된 전형적인 웹 응용 프로그램에서 매우 유용하다. 사용자가 웹 사이트를 항해할 때, 브라우저의 주소 창은 새로운 URL로 업데이트되며, 나중에 이 주소를 다시 방문하기 위해 이메일에 붙여넣거나 즐겨찾기에 추가할 수 있다. 뒤로 이동, 앞으로 이동 버튼들도 올바르게 동작하며, 사용자는 방문했던 페이지들을 자유로이 이동할 수 있다.

그러나, 에이잭스 응용 프로그램은 웹 페이지 하나에서 동작하는 복잡한 프로그램이기 때문에 예외적인 응용 프로그램이다. 브라우저는 이런 기능을 위해 만들어지지 않았다. 웹 응용 프로그램들이 마우스 클릭을 할 때마다 완전히 새로운 페이지를 가져올 수 있게 되었어도 브라우저는 과거에 사로잡혀 있다.

지메일과 같은 AJAX 소프트웨어에서 사용자가 기능을 선택하고, 응용 프로그램의 상태를 바꾸어도 브라우저의 주소창은 항상 같은 위치만 갖고 있기 때문에 응용 프로그램의 특정 화면에 대해 즐겨찾기를 축가하는 것은 불가능하다. 뿐만 아니라, 사용자가 이전 작업을 원상태로 되돌리기위해 뒤로 이동 버튼을 클릭하면 브라우저가 응용 프로그램의 웹 페이지를 떠나기 때문에 사용자들은 놀라게 된다.

해결책

오픈소스 RSH(Really Simple History) 프레임워크는 이러한 문제를 해결하고, 에이잭스 응용 프로그램에서 즐겨찾기, 뒤로 이동, 앞으로 이동을 제어할 수 있게 해준다. RSH는 현재 베타 버전이며, 파이어폭스 1.0, 넷스케이프 7 이상, 인터넷 익스플로러 6 이상의 버전에서 동작하며, 사파리는 현재 지원되지 않는다.(이에 대한 설명은 나의 웹 로그에서 Coding in Paradise: Safari: No DHTML History Possible를 참고하기 바란다.)

몇몇 에이잭스 프레임워크는 현재 즐겨찾기와 히스토리 문제를 해결하려 하고 있지만 이들 프레임워크는 구현 방식 때문에 몇가지 중요한 버그들을 해결하지 못하고 있다.(보다 자세한 사항은 "Coding in Paradise: AJAX History Libraries"를 참고한다) 게다가, 많은 에이잭스 ^[2]히스토리 프레임워크는 Backbase나 Dojo 같은 보다 큰 라이브러리안에 통합된 형태로 되어 있다. 이들 프레임워크는 AJAX 응용 프로그램에 대해서 완전히 다른 프로그래밍 모델을 제공하고 있으며, 개발자가 히스토리 기능을 사용하기 위해서는 완전히 새로운 접근방법을 사용할 것을 강요받게 된다.

(^[2]역주: 히스토리(History)는 "기록" 또는 "방문기록"으로 옮기지만 대부분이 히스토리에 익숙하기 때문에 번역하지 않았다)

반면에, RSH는 기존 AJAX 시스템에 포함시킬 수 있는 간단한 모듈로 되어 있다. 뿐만 아니라, RSH 라이브러리는 다른 히스토리 프레임워크들이 갖고 있는 버그들을 피하기 위한 기술들을 사용하고 있다.

RSH 히스토리 프레임워크는 자바스크립트 클래스 DhtmlHistory, HistoryStorage로 구성되어있다.

DhtmlHistory 클래스는 에이잭스 응용 프로그램을 위한 히스토리 추상화를 제공한다. 즉, 에이잭스 페이지는 브라우저에 새 위치와 그에 대한 히스토리 데이터를 지정한 히스토리 이벤트를 추가하는 add()를 호출한다. DhtmlHistory 클래스는 A 태그에 #new-location과 같은 해쉬를 사용해서 브라우저의 현재 URL을 업데이트하고, 히스토리 데이터와 새 URL을 연결한다. 에이잭스 응용 프로그램 자체를 히스토리 리스너(listener)로 등록하고, 사용자가 뒤로 이동, 앞으로 이동 버튼을 사용해서 이동할 때 마다 히스토리 이벤트는 add() 호출로 저장했던 히스토리 데이터와 브라우저의 위치를 제공한다.

개발자는 HistoryStorage 클래스를 사용해서 어떤 크기의 히스토리 데이터라도 저장할 수 있다. 일반 페이지에서 사용자가 새로운 웹 사이트로 이동할 때 브라우저는 이전 웹 페이지의 모든 응용 프로그램을 제거하고, 응용 프로그램과 자바스크립트의 상태를 정리한다. 따라서, 사용자가 뒤로 이동 버튼을 사용하여 이전 페이지로 돌아가면 모든 데이터가 사라진다. HistoryStorage 클래스는 put(), get(), hasKey()와 같은 간단한 해쉬 테이블 메서드를 제공하는 API를 통해서 이 문제를 해결한다. 사용자가 웹 페이지를 떠난 다음에도 개발자는 이들 메서드를 사용해서 데이터를 저장할 수 있다. 사용자가 뒤로 이동 버튼을 사용해서 돌아오면 HistoryStorage 클래스를 사용해서 데이터에 접근할 수 있다. 이 기능은 사용자가 웹 페이지를 떠난 후에도 브라우저가 폼 양식에 있는 값들을 자동으로 저장한다는 사실을 이용한 것으로, 숨겨진 폼 필드를 사용해서 구현됐다.

예제

이제 바로 간단한 예제로 살펴보자.

먼저, RSH 프레임워크를 사용할 페이지는 dhtmlHistory.js 스크립트를 반드시 인클루드해야 한다.

<!-- Load the Really Simple
       History framework -->
<script type="text/javascript"
            src="../../framework/dhtmlHistory.js">
</script>

DHTML 히스토리 응용 프로그램은 에이잭스 웹 페이지가 있는 디렉터리에 blank.html 파일을 포함시켜야 한다. 이 파일은 RSH 프레임워크에 함께 들어있으며, 인터넷 익스플로러에서 사용한다. 여담이지만, 인터넷 익스플로러는 히스토리 변경 사항을 추적하고 추가하기 위해 "숨겨진 iframe"을 사용한다. 히스토리 기능이 제대로 동작하기 위해서는 실제 위치를 가리키는 것이 필요한데, 이를 위해 비어있는 iframe을 사용한다. 그래서 이름도 blank.html이다.

RSH 프레임워크는 브라우저 히스토리를 조작하기 위한 진입점으로 dhtmlHistory라는 전역 객체를 생성한다. dhtmlHistory로 작업하는 첫번째 단계는 페이지 로딩이 끝난 후에 이 객체를 초기화하는 것이다.

window.onload = initialize;
     
function initialize() {
   // initialize the DHTML History
   // framework
   dhtmlHistory.initialize();

다음으로, 개발자는 히스토리 변경 이벤트를 ^[3]구독하기 위해 dhtmlHistory.addListener()를 사용해야 한다. 이 메서드는 DHTML 히스토리가 변경될 때, 페이지의 새로운 위치, 히스토리 변경 이벤트와 관련된 히스토리 데이터를 인자로 받는 콜백 함수를 인자로 받는다.

(^[3]역주: 이벤트 구독보다는 이벤트 감시가 더 적절한 표현이지만 원문이 subscribe이므로 구독으로 옮김)

window.onload = initialize;
     
function initialize() {
// DHTML 히스토리 프레임워크를 초기화한다
   dhtmlHistory.initialize();
   
// HTML 히스토리 변경 이벤트를 구독한다
   dhtmlHistory.addListener(historyChange);

historyChange() 메서드는 사용자가 새 위치로 이동한 후의 newLocation과 히스토리 변경 이벤트와 관계된 historyData를 인자로 받는 함수로 이해하기 쉽다.

/** 히스토리 변경 이벤트를 받기 위한 콜백 */
function historyChange(newLocation,
                                  historyData) {
   debug("A history change has occurred: "
            + "newLocation="+newLocation
            + ", historyData="+historyData,
            true);
}

위에서 사용한 debug() 메서드는 예제 소스 파일에 정의된 유틸리티 함수로 전체 예제 안에 포함되어 있다. debug()는 웹 페이지안에 메시지를 출력한다. 두번째 인자는 불리언(boolean) 타입으로 위 인자에서는 true를 사용했다. true를 사용하면 앞의 메시지를 모두 정리한 다음에 새로운 디버그 메시지를 출력한다.

개발자는 add() 메서드를 사용해서 히스토리 이벤트를 추가한다. 히스토리 이벤트를 추가하는 것은 edit:SomePage와 같이 히스토리 변경 이벤트와 함께 저장할 historyData 값을 제공하기 위한 새 위치를 지정하는 것이다.

window.onload = initialize;
     
function initialize() {
   // initialize the DHTML History
   // framework
   dhtmlHistory.initialize();
   
   // subscribe to DHTML history change
   // events
   dhtmlHistory.addListener(historyChange);
         
   // if this is the first time we have
   // loaded the page...
   if (dhtmlHistory.isFirstLoad()) {
      debug("Adding values to browser "
               + "history", false);
      // start adding history
      dhtmlHistory.add("helloworld",
                               "Hello World Data");
      dhtmlHistory.add("foobar", 33);
      dhtmlHistory.add("boobah", true);
         
      var complexObject = new Object();
      complexObject.value1 =
                           "This is the first value";
      complexObject.value2 =
                           "This is the second data";
      complexObject.value3 = new Array();
      complexObject.value3[0] = "array 1";
      complexObject.value3[1] = "array 2";
         
      dhtmlHistory.add("complexObject",
                               complexObject);

add()를 호출하는 즉시 사용자 브라우저의 URL 툴바에 새로운 위치가 표시된다. 예를 들어, http://codinginparadise.org/my_ajax_app 주소의 에이잭스 웹 페이지에서 dhtmlHistory.add( "helloworld", "Hello World Data" )를 호출하면 사용자는 브라우저의 URL 툴바에서 다음 주소를 보게 된다.

http://codinginparadise.org/my_ajax_app#helloworld

사용자는 이 페이지를 북마크할 수 있다. 사용자가 이 북마크를 이용하면 에이잭스 응용 프로그램은 #helloworld 값을 읽어서 웹 페이지를 초기화할 수 있다. 해시 # 다음의 위치 정보는 RSH 프레임워크에 의해 투명하게 인코딩과 디코딩이 수행된다.

historyData는 URL을 사용하는 것 보다 쉽게 에이잭스 위치 변화에 따른 복잡한 상태들을 저장할 수 있게 해준다. historyData는 숫자, 문자열, 객체와 같은 자바스크립트 타입으로 사용할 수 있는 값이다. 이를 사용하는 예로는 사용자가 DHTML 텍스트 에디터에서 다른 페이지로 이동하는 경우에 에디터의 내용을 모두 저장하는 것이다. 사용자가 뒤로 이동 버튼을 클릭해서 다시 DHTML 페이지로 돌아오면 브라우저는 히스토리 변경 리스너에게 객체를 돌려주게 된다.

개발자는 중첩된 객체나 복잡한 상태를 표현하는 배열과 같은 자바스크립트 객체 전체를 historyData에 사용할 수 있다. 히스토리 데이터에는 간단한 데이터 타입이나 NULL 타입 뿐만 아니라 JSON(자바스크립트 객체 표기법)으로 표현할 수 있는 무엇이든 될 수 있다. 그러나, DOM 객체에 대한 참조나 XMLHttpRequest와 같은 스크립트 가능한 브라우저 객체는 저장되지 않는다. historyData는 북마크와 함께 보존되는 데이터가 아니며, 브라우저를 종료하거나, 브라우저 캐시를 제거하거나, 사용자가 히스토리를 정리하면 사라지는 데이터이다.

dhtmlHistory를 사용하는 마지막 단계는 isFirstLoad() 메서드이다. 어떤 브라우저에서는 웹 페이지를 항해할 때 다른 페이지로 이동했다가 뒤로 이동 버튼을 눌러서 처음 사이트로 돌아오면 첫번째 페이지가 완전히 재로딩되고 onload 이벤트가 발생한다. 페이지를 반복적으로 재로딩하는 경우가 아니라 처음 로드될 때만 특별한 방법으로 초기화하길 원하는 코드를 망쳐버릴 수 있다. isFirstLoad() 메서드는 웹 페이지를 처음 로드한 경우와 사용자가 브라우저 히스토리에 저장된 웹 페이지에서 뒤로 이동한 경우를 구별해준다.

예제 코드에서는 페이지가 처음 로드되었을 때 히스토리 이벤트를 추가하길 원한다. 페이지가 로드된 다음에 사용자가 페이지로 돌아가기 위해 뒤로 이동 버튼을 누른 경우에는 히스토리 이벤트를 추가하지 않는다.

window.onload = initialize;
     
function initialize() {
   // initialize the DHTML History
   // framework
   dhtmlHistory.initialize();
   
   // subscribe to DHTML history change
   // events
   dhtmlHistory.addListener(historyChange);
         
   // if this is the first time we have
   // loaded the page...
   if (dhtmlHistory.isFirstLoad()) {
      debug("Adding values to browser "
               + "history", false);
      // start adding history
      dhtmlHistory.add("helloworld",
                               "Hello World Data");
      dhtmlHistory.add("foobar", 33);
      dhtmlHistory.add("boobah", true);
         
      var complexObject = new Object();
      complexObject.value1 =
                           "This is the first value";
      complexObject.value2 =
                           "This is the second data";
      complexObject.value3 = new Array();
      complexObject.value3[0] = "array 1";
      complexObject.value3[1] = "array 2";
         
      dhtmlHistory.add("complexObject",
                               complexObject);

이제 historyStorage 클래스를 살펴보자. dhtmlHistory, historyStorage와 마찬가지로 historyStorage라는 전역 객체 하나를 통해서 모든 기능을 제공한다. 이 객체는 해시 테이블을 시뮬레이션 하기 위해 put(keyName, keyValue0, get(keyName), hasKey(keyName)과 같은 메서드를 제공한다. 키 이름은 반드시 문자열이어야하며, 키 값은 XML로 된 문자열이나 자바스크립트 객체와 같이 복잡한 것도 사용할 수 있다. 예제에서는 페이지가 처음 로드될 때 historyStorage안에 간단한 XML을 저장하기 위해 put()을 사용하고 있다.

window.onload = initialize;
     
function initialize() {
   // initialize the DHTML History
   // framework
   dhtmlHistory.initialize();
   
   // subscribe to DHTML history change
   // events
   dhtmlHistory.addListener(historyChange);
         
   // if this is the first time we have
   // loaded the page...
   if (dhtmlHistory.isFirstLoad()) {
      debug("Adding values to browser "
               + "history", false);
      // start adding history
      dhtmlHistory.add("helloworld",
                               "Hello World Data");
      dhtmlHistory.add("foobar", 33);
      dhtmlHistory.add("boobah", true);
         
      var complexObject = new Object();
      complexObject.value1 =
                           "This is the first value";
      complexObject.value2 =
                           "This is the second data";
      complexObject.value3 = new Array();
      complexObject.value3[0] = "array 1";
      complexObject.value3[1] = "array 2";
         
      dhtmlHistory.add("complexObject",
                               complexObject);
                              
      // cache some values in the history
      // storage
      debug("Storing key 'fakeXML' into "
               + "history storage", false);
      var fakeXML =
         '<?xml version="1.0" '
         +         'encoding="ISO-8859-1"?>'
         +         '<foobar>'
         +             '<foo-entry/>'
         +         '</foobar>';
      historyStorage.put("fakeXML", fakeXML);
   }

다음으로, 사용자가 다른 페이지로 이동한 다음에 뒤로 이동 버튼을 통해 돌아온 경우에 get() 메서드를 사용해서 저장된 값을 가져올 수 있고, hasKey()를 사용해서 키가 있는지 확인할 수 있다.

window.onload = initialize;
     
function initialize() {
   // initialize the DHTML History
   // framework
   dhtmlHistory.initialize();
   
   // subscribe to DHTML history change
   // events
   dhtmlHistory.addListener(historyChange);
         
   // if this is the first time we have
   // loaded the page...
   if (dhtmlHistory.isFirstLoad()) {
      debug("Adding values to browser "
               + "history", false);
      // start adding history
      dhtmlHistory.add("helloworld",
                               "Hello World Data");
      dhtmlHistory.add("foobar", 33);
      dhtmlHistory.add("boobah", true);
         
      var complexObject = new Object();
      complexObject.value1 =
                           "This is the first value";
      complexObject.value2 =
                           "This is the second data";
      complexObject.value3 = new Array();
      complexObject.value3[0] = "array 1";
      complexObject.value3[1] = "array 2";
         
      dhtmlHistory.add("complexObject",
                               complexObject);
                              
      // cache some values in the history
      // storage
      debug("Storing key 'fakeXML' into "
               + "history storage", false);
      var fakeXML =
         '<?xml version="1.0" '
         +         'encoding="ISO-8859-1"?>'
         +         '<foobar>'
         +             '<foo-entry/>'
         +         '</foobar>';
      historyStorage.put("fakeXML", fakeXML);
   }
   
   // retrieve our values from the history
   // storage
   var savedXML =
                     historyStorage.get("fakeXML");
   savedXML = prettyPrintXml(savedXML);
   var hasKey =
                historyStorage.hasKey("fakeXML");
   var message =
      "historyStorage.hasKey('fakeXML')="
      + hasKey + "<br>"
      + "historyStorage.get('fakeXML')=<br>"
      + savedXML;
   debug(message, false);
}

preetyPrintXml()은 전체 예제에 포함된 유틸리티 메서드로 디버깅을 위해 웹 페이지에 XML을 출력한다.

데이터는 오직 현재 페이지의 히스토리에서만 유지된다는 점에 주의해야 한다. 즉, 브라우저를 종료하거나 사용자가 새로운 창을 열고 에이잭스 응용프로그램의 주소를 다시 입력하는 경우에 히스토리 데이터는 이용할 수 없다. 히스토리 데이터는 오직 뒤로, 앞으로 이동 버튼에 한해서만 유지된다. 사용자가 브라우저를 종료하거나 캐시를 정리하면 사라진다. 실제로, 오랜시간 유지할 수 있는 방법을 원한다면 에이잭스 대용량 저장 시스템(AMAXX, Ajax Massive Storage System)을 보기 바란다.

예제는 이것으로 끝났으며, 데모를 체험해보거나 전체 소스 코드를 다운로드하기 바란다.

예제2: 오라일리 메일

두번째 예제는 Gmail과 유사한 오라일리 메일이라는 가짜 AJAX 이메일 응용프로그램이다. 오라일리 메일을 통해 dhtmlHistory 클래스를 사용해서 브라우저 히스토리를 제어하는 방법, historyStorage 객체를 사용해서 히스토리 데이터를 캐시하는 방법에 대해 설명할 것이다.

오라일리 메일 사용자 인터페이스는 두 부분으로 구성되어 있다. 페이지의 왼쪽 사이즈는 받은 편지(Inbox), 임시 보관(Draft) 같은 다양한 이메일 폴더와 옵션으로 구성된 메뉴다. 사용자가 받은 편지 같은 메뉴를 선택하면 페이지의 오른쪽에 내용을 업데이트한다. 실제 응용프로그램에서는 선택된 메일박스의 내용을 가져와서 표시해야하지만 오라일리 메일에서는 선택한 옵션만 간단하게 보여준다.

오라일리 메일은 브라우저 히스토리에 메뉴 변경사항을 추가하고, 위치 바를 업데이트하는데 RSH 프레임워크를 사용하기 때문에 사용자가 응용프로그램을 북마크하고 브라우저의 뒤로, 앞으로 이동 버튼을 사용해서 메뉴 변경 이전으로 이동할 수 있다.

historyStorage 사용법을 설명하기 위해 Address Book(주소록)이라는 메뉴를 추가했다. 주소록은 이름과 이메일 주소를 자바스크립트 배열로 저장하고 있지만 실제 응용프로그램이라면 원격 서버에서 배열 내용을 가져와야 할 것이다. 그러나, 오라일리 메일에서는 배열을 직접 생성하고, 이름과 이메일 주소를 몇 개 추가한 다음에 historyStorage 객체에 저장한다. 사용자가 웹 페이지를 떠난후에 돌아오면 오라일리 메일 응용프로그램은 원격 서버에서 접속하는 대신 캐시에서 주소록을 가져온다.

주소록은 initialize() 메서드에서 저장하고 가져올 수 있다.

/** 페이지가 로딩을 끝낸 후에 초기화를 수행하는 함수 */
function initialize() {
    // DHTML 히스토리 프레임워크를 초기화한다
    dhtmlHistory.initialize();
   
    // DHTML 히스토리 리스너에 등록한다
    dhtmlHistory.addListener(handleHistoryChange);

    // 주소록을 가져올 수 없으면 직접 추가한 주소록을
    // 히스토리 저장소에서 캐싱한다.
   if (window.addressBook == undefined) {
         // 주소록을 전역 객체로 저장한다
       // 실제 응용프로그램에서는 백그라운드에서 서버로부터
       // 주소록을 가져와야한다
         window.addressBook =
             ["Brad Neuberg 'bkn3@columbia.edu'",
               "John Doe 'johndoe@example.com'",
               "Deanna Neuberg 'mom@mom.com'"];
               
         // 주소록이 있으면 이를 캐시에 보관한다
       // 사용자가 페이지를 떠난 후에 뒤로 이동으로 돌아온 경우에도 사용한다
       historyStorage.put("addressBook",
                                     addressBook);
    }
    else {
         // 히스토리 저장소에서 캐시된 주소록을 가져온다
         window.addressBook =
                      historyStorage.get("addressBook");
    }

히스토리 변경을 다루는 코드는 이해하기 쉽다. 아래 코드에서처럼 사용자가 뒤로 또는 앞으로 이동 버튼을 클릭할 때 handleHistoryChange가 호출된다. 그러면 newLocation을 갖게 된다. 이를 이용해서 사용자 인터페이스를 올바른 상태로 업데이트할 수 있다.

/** 히스토리 변경 이벤트를 처리한다 */
function handleHistoryChange(newLocation,
                                           historyData) {
    // 위치가 없으면 수신함의 기본 위치를 보여준다
    if (newLocation == "") {
         newLocation = "section:inbox";
    }
   
    // 위치 변화가 있으면 표시할 섹션을 추출한다.
    // newLocation은 "section:"으로 시작한다
    newLocation =
             newLocation.replace(/section\:/, "");
   
    // DHTML 히스토리 변경에 따라 브라우저를 업데이트한다
    displayLocation(newLocation, historyData);
}

/** 오른쪽 컨텐트 영역에 주어진 위치를 표시한다*/
function displayLocation(newLocation,
                                     sectionData) {
    // 선택한 메뉴 항목을 가져온다
    var selectedElement =
                  document.getElementById(newLocation);
                 
    // 이전에 선택된 메뉴 항목을 제거한다
    var menu = document.getElementById("menu");
    for (var i = 0; i < menu.childNodes.length;
                                                               i++) {
         var currentElement = menu.childNodes[i];
         // DOM 요소 노드인지 확인한다
         if (currentElement.nodeType == 1) {
             //모든 클래스 이름을 제거한다
             currentElement.className = "";
         }                                                         
    }
   
    // UI에서 다르게 나타나는 새로 선택된 메뉴 항목
    selectedElement.className = "selected";
   
    // 화면 오른쪽에 새로운 섹션을 표시한다.
    // sectionData에 따라 섹션을 결정한다

    // 앞서 캐시된 로컬 주소 데이터를 사용해서 주소록을 보여준다
    if (newLocation == "addressbook") {
         // 주소록을 보여준다
         sectionData = "<p>Your addressbook:</p>";
         sectionData += "<ul>";
         
         // 주소록이 아직 없다면 캐시에서 주소록을 가져온다
         if (window.addressBook == undefined) {
             window.addressBook =
                      historyStorage.get("addressBook");
         }
         
         // 주소록을 표시한다
         for (var i = 0;
                      i < window.addressBook.length;
                               i++) {
             sectionData += "<li>"
                                    + window.addressBook[i]
                                    + "</li>";                          
         }
         
         sectionData += "</ul>";
    }
   
    // sectionData가 없다면 원격으로 가져온다. 이 예제에서는 주소록을 제외한
    // 모든 데이터는 가짜를 이용하고 있다
    if (sectionData == null) {
         // 실제 응용프로그램에서는 섹션의 내용을 원격으로 가져와야한다
         sectionData = "<p>This is section: "
             + selectedElement.innerHTML + "</p>";  
    }
   
    // 제목과 내용을 업데이트한다
    var contentTitle =
             document.getElementById("content-title");
    var contentValue =
             document.getElementById("content-value");
    contentTitle.innerHTML =
                                    selectedElement.innerHTML;
    contentValue.innerHTML = sectionData;
}

오라일리 메일 데모를 체험하거나 소스 코드를 다운로드할 수 있다.

결론

RSH(Really Simple History) API를 사용해서 에이잭스 응용프로그램에서 즐겨찾기와 뒤로, 앞으로 이동 버튼을 사용하기 위한 방법을 보았으며 직접 에이잭스 응용프로그램을 작성하는데 발판이 될 수 있는 예제 코드들을 살펴보았다. 나는 즐겨찾기와 히스토리를 완전히 지원하는 여러분의 에이잭스 발명품들을 볼 수 있기를 기대한다.

감사의 글

이 글을 검토해준 모든 사람과 RSH 프레임워크를 제작한 모두에게 감사드린다: Michael Eakes, Jeremy Sevareid, David Barrett, Brendon Wilson, Dylan Parker, Erik Arvidsson, Alex Russell, Adam Fisk, Alex Lynch, Joseph Hoang Do, Richard MacManus, Garret Wilson, Ray Baxter, Chris Messina, and David Weekly.

참고자료

• 이 기사의 모든 소스코드 다운로드
• RSH 프레임워크 다운로드
• 오라일리 메일 데모와 오라일리 메일 소스 코드 다운로드. 전체 예제 다운로드에는 시험할 수 있는 보다 많은 예제들이 있다
• Coding in Paradise(코딩천국): AJAX, DHTML, 자바 기술, 위키위키와 같은 협업 기술 등을 다루는 저자의 웹로그
• "Coding in Paradise: AJAX: Bookmarks and Back Buttons, Advanced Example"
• "Coding in Paradise: Safari: No DHTML History Possible"
• "Coding in Paradise: AJAX Tutorial: Saving Session Across Page Loads Without Cookies, On The Client Side"
• "Coding in Paradise: AJAX History Libraries"

Bard Neuberg는 모질라, JXTA, 자카르타 피드 파서 등에 코드를 공헌하고 있으며, 오픈소스 커뮤니티에서 폭넓은 공헌을 하고 있다.

출처 - http://network.hanbitbook.co.kr/view.php?bi_id=1162