코드 검사자
코드 검사자 (Code Inspectors)
검사자(inspector)가 구조체 필드에 대한 접근을 통제하는 것과 같은 방식으로, 검사자는 모듈 바인딩에 대한 접근도 통제해요. 이런 용도로 쓰이는 검사자를 *코드 검사자(code inspector)*라고 부릅니다. 모듈 바인딩에 대한 기본 코드 검사자는 current-inspector 파라미터가 아니라 current-code-inspector 파라미터가 결정합니다.
본문
구조체 필드에 대한 접근을 검사자가 통제하는 것과 같은 방식으로(Structure Inspectors 참조), 검사자는 모듈 바인딩에 대한 접근도 통제해요. 이런 식으로 쓰이는 검사자를 코드 검사자라고 합니다. 모듈 바인딩에 대한 기본 코드 검사자는 current-inspector 파라미터가 아니라 current-code-inspector 파라미터가 결정해요.
module 선언을 평가하면, current-code-inspector 파라미터의 값이 그 모듈 선언에 연관됩니다. require나 dynamic-require로 모듈을 호출(invoke)하면, 모듈의 선언 시점 검사자의 서브 검사자(sub-inspector)가 만들어지고 이 서브 검사자가 모듈 호출에 연관돼요. 서브 검사자를 통제하는 어떤 검사자(선언 시점 검사자와 그 상위 검사자 포함)라도 모듈 호출을 통제합니다. 특히 current-code-inspector의 값이 절대 바뀌지 않으면, 모듈의 호출이 current-code-inspector의 서브 검사자와 연관되므로 어떤 모듈 호출에서도 통제를 잃지 않아요.
current-code-inspector로 모듈 호출을 통제하는 검사자를 설치하면, 그 검사자를 통해 모듈에 module->namespace를 사용할 수 있고, 모듈의 보호된(protected) 내보내기(즉 protect-out으로 모듈에서 내보낸 식별자)에 dynamic-require로 접근할 수 있게 됩니다. 모듈은 자신의 선언 시점 코드 검사자보다 더 약한 코드 검사자를 가진 모듈을 require할 수 없어요.
module 형식을 확장하거나 네임스페이스를 만들면, current-code-inspector의 값이 모듈 또는 네임스페이스의 최상위 렉시컬 정보에 연관됩니다. 그 렉시컬 정보를 가진 문법 객체는 그 검사자가 통제하는 어떤 모듈의 보호된/미내보기 바인딩에도 접근할 수 있게 되죠. module의 경우, 문법 객체가 덜 강력한 맥락의 코드 확장에 쓰이더라도 검사자는 그런 문법 객체에 계속 붙어 있어요. 게다가 문법 객체가 컴파일된 변수 참조인 식별자라면, 그 변수 참조가 더 약한 검사자로 평가(즉 선언)된 module 형식 안에 나타나더라도 검사자는 변수 참조에 계속 붙어 있습니다. 문법 객체나 변수 참조가 컴파일된 코드 안에서 인쇄될 때(Printing Compiled Code 참조) 연관된 검사자는 보존되지 않아요.
인쇄된 형태의 컴파일 코드를 read로 다시 읽으면 코드에 연관된 검사자가 없습니다. 코드를 eval하면, 인스턴스화된 문법 객체 리터럴과 모듈 변수 참조가 current-code-inspector의 값을 자신의 검사자로 갖게 돼요.
모듈 인스턴스화가 각자 모듈 레지스트리를 가진 여러 네임스페이스에 붙어 있으면, 모듈 호출의 검사자는 레지스트리별로 달라질 수 있어요. 특정 모듈 레지스트리의 호출 검사자는 namespace-unprotect-module로 바꿀 수 있습니다(단 검사자를 바꾸려면 기존 검사자에 대한 통제권이 있어야 해요).
버전 8.1.0.8 (패키지 base)에서 변경: 더 약한 코드 검사자를 가진 모듈을 require하는 것에 대한 제약이 추가됨.
파라미터
(current-code-inspector) → inspector?
(current-code-inspector insp) → void?
insp : inspector?
모듈 바인딩과 재정의에 대한 접근을 통제할 검사자를 결정하는 파라미터예요.
코드 검사자를 원래 값에서 바꾸면, 기본 compiled-load 핸들러가 로드한 바이트코드는 실행 불가(non-runnable)로 표시됩니다.