1. 프로토타입에 대해

ECMAscript의 전반적인 출발점을 다시 짚어보죠. 원래 이 스크립트 엔진의 취지가 동적으로 가벼운 동작을 처리하기 위해 고안된 엔진입니다. 따라서 철저하게 컴파일타임이 없고 모든 처리는 런타임에서 한다는 것을 기본으로 하고 있습니다. 따라서 모든 데이터는 전부 런타임에 동적으로 메모리에 적재됩니다. 이 뜻은 동적으로 로딩되어있기 때문에 추가,수정,삭제가 아무렇게나 가능하다라는 의미입니다.
클래스의 정의, 함수의 정의 등은 일반적인 언어에서 별도의 고정된 메모리공간에 저장하여 호스트가 런타임에 건드릴 수 없게 보호하지만, ECMAscript에서는 이 마저도 전부 동적 메모리 공간에 갖고 있고 런타임에 자유롭게 바꿀 수 있습니다. 프로토타입은 런타임에 동적메모리공간에 저장되는 여러가지 데이터중 객체와 함수의 정의를 담아두는 전역 변수의 일종입니다.

여기서 프로토타입이 상속하거나 확장하는 구조를 당연하게 이해할 수 있습니다. 변수 같은 것이니 프로토타입에 뭔가 추가하거나 삭제하면 그걸 참조하고 있는 모든 객체(인스턴스)에게 영향을 끼치게되는 특성은 어찌보면 필연적이라 하겠습니다.

2. 액션스크립트에서의 프로토타입

플래시는 swf로 중간코드컴파일이 됩니다(어쨌든 컴파일이 됩니다 ^^) 근데 위와 같은 프로토타입이 필요할까요? 사실 필요 없을 뿐더러 사용하면 안됩니다. 모처럼 컴파일언어인데, 그 장점을 싸그리 날려버리는 셈이니까요. 컴파일언어의 장점은 컴파일타임에 컴파일러가 형검사를 해준다는 것입니다. 컴파일러는 미리 정한 형을 먼저 메모리에 담고 그 여러가지 사용자 정의형이 코드에서 올바로 씌였는가를 일일히 검사합니다. 이것에 대형개발을 가능하게 하죠(사람이 확인할 수 있는 코드라는게 기껏해야 천 줄 정도일까요)

하지만, as는 프로토타입을 사용하고 있습니다. 화딱지 나는거죠. as2까지는 정말 피해가 심각했습니다. 하지만 as3에서 어도비가 매크로미디어라는 구멍가게를 인수하자 확실히 큰 회사의 시각으로 뜯어 고쳤습니다. 그래서 프로토타입을 없애버렸으면 좋았겠지만 모든 차기버전의 짐인 기존 버전과의 호환 문제 때문에 지우지 못하고 동시 지원하는 기형적인 형태를 만들었습니다. 재밌는 사실은 기존 프로토타입의 메쏘드 호환을 위해, 기존 모드로 작동할 때와 새로운 strict모드로 동작할 때를 분리하여 같은 이름이 작동하게 하기 위해 네임스페이스시스템을 만들었다는 겁니다(네임스페이스는 나중에 다루기로 하죠. 쨌든 strict모드는 AS3네임스페이스로 작동하게 됩니다)

원래 프로토타입에서 인스턴스를 생성한 경우 자신의 메쏘드나 프로퍼티를 사용하기 위해서는 프로토타입 전체를 이름으로 뒤져서 해당객체를 찾은 뒤 자신의 데이터를 위임하여 실행합니다. 이 과정을 네임룩업이라고 합니다. 객체가 많을수록 인스턴스가 많을수록 심각하게 느려지는 원인이 되죠. 신형 브라우저의 자바스크립트엔진은 이 부분을 상당히 꽁수로 개선해 출시되고 있습니다. 그렇게 따지면 AVM2도 그 꽁수 중에 한 가지 형태라고 볼 수 있습니다.

AVM2에서는 객체를 생성할 때 프로토타입으로부터 해당 객체와 관련된 모든 정보체인을 받아와 두 개의 캐쉬 테이블을 만들어냅니다. 하나는 const등으로 정의한 고정값 캐쉬 테이블이고, 다른 하나는 var나 function으로 정의된 속성 및 메쏘드 캐쉬 테이블입니다. 이 캐쉬테이블은 인스턴스마다 만들어지는게 아니라 객체(클래스)의 정의마다 만들어지며 내부적으로는 traits라는 객체로 생성되어, 한 번 생성된 후 메모리에 고정되어 빠르게 읽을 수 있게 처리됩니다. 하지만 traits객체는 런타임시에도 생성할 수 있습니다. 그걸 통해 동적클래스로딩이 어플리케이션 도메인 설정이 가능합니다.

3. 교훈

딱 까놓고 말해 as3가 여전히 느립니다. 적어도 자바수준의 실행능력을 확보하려면 하루 빨리 프로토타입을 버려야합니다. 일단 봉인된 클래스 위주의 as3가 기존의 플래시컨텐츠를 적당히 대체하면 as4정도에서는 완전히 프로토타입을 몰아내길 바랍니다.