Beyond Web

2. 주요 기능 (Freatures at a Glance)

OOP

객체지향 프로그래밍은 Java와 같은 언어에서 존재하는 class와 interface를 통해 지원된다. (이 두 가지는 nominal type으로 알려져 있다.) 클래스 기반 프로그램밍은 프로그램을 만들고 재사용 가능한 라이브러리를 만드는데 있어 잘 알려진 방법이며 널리 가르쳐져 왔다. 게다가 웹 환경에서의 ECMAScript의 환경인 브라우저의 Document Object Model (DOM)은 class와 interface로 이우러져있다. ECMAScript를 확장 언어로 사용하는 다른 환경 역시 주로 클래스 기반 구조체에 의해 가장 잘 실현되는 객체 모델을 노출한다.

ES3에서 사용되던 Delegation 형식의 프로그래밍은 여전히 ES4에서 지원되며, 실제로도 클래스 기반 프로그래밍과 잘 융합된다.

마지막으로 ES4는 Multimethod 메커니즘을 이용해 Common Lisp, Dylan, Cecil 등에서 사용되는 프로그래밍 스타일을 지원한다. (이들 언어에서는 메서드의 정의는 메서드가 적용되는 타입의 정의와 결합되지 않는다.) Multimethod는 ES4가 연산자 오버로딩을 지원하기 쉽도록 한다.

Privacy

Modularity, name hiding, 라이브러리 구축은 packages와 namespace에 의해 지원되는데, 이것은 서로 분리되어 있는 모듈간에 견고한 API를 제공하고 type system과 함께 이름에 대한 접근 권한을 제어하는 기능을 제공한다.

타입(Types)

크고 일반적으로 검증가능하고 고성능의 프로그래밍은 풍부한 타입 시스템에 의해 지원된다. nomial type은 class와 interface에 의해 구현되며 ES3 프로그램에서 일반적인 ad hoc 데이터를 지원하기위한 구조적 타입에 의해 보충된다.

변수는 타입 제약을 가질 수 있으며 이때 구현은 타입 검사와 early binding을 수행한다. 타입이 있는 코드와 없는 코드가 예측가능한 방법으로 공존할수 있으며 완전히 타입이 있는 코드, 타입이 있는 라이브러리와 그렇지 않은 클라이언트 코드, 타입이 있는 API (package, class 또는 function 레벨에서)와 그렇지 않은 구현 코드 또는 임의로 타입을 사용하는 것 등 다양한 스타일을 지원한다.

타입이 없는 코드가 필요에 따라 점진적으로 타입을 지정할 수 있는 것 처럼, ad hoc 데이터 역시 필요에 따라 구조적 또는 명시적 타입을 지정할 수 있다. 타입이 없는 데이터는 로컬 데이터로 사용하고 노출되는 데이터 구조는 구조적 타입을 적용하고, 성능, 보안 또는 프로그램 구조상 필요가 있을 경우 명시적 타입으로 변환하여 지정할 수 있다.

검증(Verification)

프로그램 컴포넌트는 strict mode에서 컴파일 되도록 요청할 수 있으며, 이는 해당 컴포넌트가 실행되기 이전에 검증되도록 한다. 검증 단계는 정적 타입 검사(static type checking)을 수행하며 다른 정적인 검사들을 수행한다. 주로 참조된 모든 이름이 알려져 있는지, 참조된 객체의 속성의 타입이 알려져 있는지, 상수에 대한 쓰기는 없지는지, 다른 타입 간의 비교는 없는지 등과 같은 것들이다.

ES4의 검증은 static checker와 다른 언어 특히 Action Script의 Verifier에 있는 "lint" 기능을 모델로 삼았다. 검증 기능의 규범적 정의는 이러한 정의가 없을때 보다 ECMAScript 구현간 호환성을 촉진시킬 것이다. (ECMAScript 구현은 strict mode를 구현하는 대신 모든 프로그램을 표준 모드에서 동작시킬 수 있다.)

속도와 공간 최적화(Speed and space optimization)

타입 지정 기능은 호출될 메서드를 미리 바인딩함으로써 잠재적으로 ES3에 비해 메서드 호출 비용을 낮출 수 있다. 타입 지정은 또한 run-time 타입 검사를 컴파일러가 생략할 수 있도록 한다. int, uint, double과 같은 데이터 타입은 현대의 하드웨어에서 직접적으로 매핑되며 몇몇 타입에 대한 타입 특정적인 연산자를 통해 고성능 연산을 수행할 수 있도록 한다. 성능을 주요 목표로 설계된 Vector와 같은 데이터 타입은 매우 범용적인 Array와 같은 데이터 타입의 오버헤드를 범용성을 약간 희생하면서 없어지도록 한다.

더 적게 프로그램하기(Programming in the small)

타입이 전송되는 exception handling, block scoping, 문법적 속기(shorthand) 그리고 바인딩과 대입연산자의 destructuring은 코드를 더욱 간단하고 적은 노력으로 짤 수 있도록 해준다.

제어구문(Control)

표준 iteration과 itemization 프로토콜은 객체가 iteration 인터페이스를 노출 할 수 있도록 한다. for-in과 for-each-in 구문이 이 프로토콜을 활용한다.

Generator는 함수의 동작을 중단하고 caller에게 값을 리턴 한 뒤 나중에 caller가 연산을 재개할 수 있도록 한다.

Proper tail call은 재귀적 또는 상호 재귀적인 함수가 반복적인 형태로 표현될 수 있도록 한다. Tail call은 스택 공간의 부족에 대한 걱정 없이 절자척인 추상화를 사용할 수 있도록 한다.

데이타(Data)

ES4는 파라메터 있는 class, getter와 setter가 있는 클래스, 타입 있는 객체와 배열 구문, meta-level hook, reflection, destructuring, 프로그래머가 정의한 객체를 predefined 객체와 같이 사용할 수 있도록 하는 타입 시스템과 같은 기능을 제공한다.

Self-hosting

ES3는 이러한 사실을 언급하지 않았지만 ES3의 Object, Array와 같은 predefined data type은 class와 interface와 같은 nominal type으로 가장 잘 실현된다. 결과적으로 ES4에 있는 Object부터 Map까지의 모든 predefined 타입은 표준에서 언어 자체를 이용하여 정의되었다. 그래서 3rd edition에서 Array는 설명문과 Pseudocode로 정의된 메서드와 속성의 집합으로 표현되었으나, ES4에서는 클래스로 표현된며 ES4 code를 활용한 설명은 메서드의 의미를 필연적으로 설명문에 의한 것 보다 정확이 정의하고 data type의 완전한 의미를 포함한다.

Self-hosting은 언어 설계 과정에서 명확한 목표였다. Self-hosting은 두 가지 긍정적인 효과가 있다. 하나는 언어의 정의에 있어서 임의로 언어에서 정의되는 부분의 필요성을 줄여주고, 언어 자체에서 제공하는 기능과 동일한 강력한 기능을 사용자에게 제공한다. 이로인해 ES4를 위한 라이브러리와 스크립트의 강건한 체계를 만들 수 있도록 한다.

Portability

ES3와 마찬가지로 ES4 역시 다양한 기계에서 동작되기를 기대한다.

완전한 ES3 구현을 가진 현대적인 웹 브라우저들은 상대적으로 느린 하드웨어와 수 메가 바이트의 메모리에서도 성공적으로 동작한다. 프로그램은 소스 텍스트 형태로 전달되며 모든 컴파일은 기기에서 이루어지지만 짧은 반응시간과 상호동작성이 중요하다. 완전한 언어 구현은 매우 중요하다. - 웹은 3rd edition compact profile과 같은 서브셋 구현과 친하지 못하다. 결과적으로 ES4는 작은 디바이스에서도 구현 가능하지만 비용이 든다. 정교한 컴파일 타임 분석이 필요한 기능은 작은 기기 뿐만 아니라 일반적으로 제외할 수 있도록 되어있다. (예를 들면 구현은 strict mode를 반드시 구현해야 하는 것은 아니다.)

마찬가지로 몇몇 ES4 구현은 JVM이나 .NET과 같은 "hosted" 환경에서 존재할 것으로 보인다. 이러한 환경은 first-class continuation이나 stack mark와 같은 강력한 기능을 제공하지 않을 수도 있으며, 따라서 ES4는 이러한 기능을 최소화 하였다.

Formalism

무엇보다 좋은 표준은 모호하지 않고 완전하며 정확해야 한다. 3rd edition 표준은 테스트 불가능하고 지정되지 않았은 low level pseudocode를 이용하여 정의하였기 때문에 의미적인 부분의 정의가 힘들었고 이로 인해 나머지는 설명문에 의해 정의되었다. 실제적으로는 충분히 정확할 수 있을런지는 모르나, pseudocode는 읽고 쓰기가 어렵다 - 많은 오류가 발견되었으며 몇몇은 비공식 정오표에 나타나있다. 가끔 설명문은 설명해야 하는 내용을 모두 설명하지 못하지만 이러한 부적절한 설명은 해당 표준을 구현하기 전까지 이를 알아 내기 어렵다.

ES4가 ES3에 비해 상당히 커질 것은 분명했다. TG1 멤버들은 문서의 내용을 디버깅하기가 너무 어려울 것이기 때문에 ES3에서 사용하던 formalism 방법을 계속 사용하고 싶지 않았다. 더 나은 formalism 방법이 요청되었으며 E4X는 구조화된 pseudocode를 사용했으나 테스트 불가능하기는 마찬가지였다. 2003년 중간 보고서는 ES3나 E4X보다 formal한 Algol과 비슷한 pseudocode를 사용했으며 이를 위한 실행 엔진도 만들어 졌다. ES4를 위한 최근의 작업에서 TG1 멤버들은 Stratego를 포함한 term rewriting 언어를 사용하는 것을 검토하였다. 하지만 결국 TG1은 ES4와 이의 모든 predefined 클래스의 완전한 참조 구현(Reference Implementation)을 만들기로 결정하였으며 4th edition 부분을 RI에서 직접 참조하기로 했다. 게다가 RI는 TG1 멤버와 커뮤니티의 사용자들이 디자인 되고 있는 언어에 대한 실험을 수행할 수 있도록 하였다.

RI의 언어 처리기 부분은 Standard ML로 구현되었고, predefined 클래스는 ECMAScript를 이용해 구현되었다. RI는 TG1 멤버들이 ES3로 쓰여진 프로그램에 대한 호환성을 가지도록 만들어진 test suite를 활용해 테스트되었다.