난 정말 최고야 멋있어
ydkjsy-scope-closures Chapter 1 ~ 2 본문
Chapter 1 Whats the Scope?
Compiled vs Interpreted
공통점 : machine-understandable 한 코드를 만든다
차이점:
Compile 은 한번에 모든 과정이 다 일어나지만 Interpretation 은 한줄씩 일어난다
Compiling Code
고전 컴파일러 이론에서의 3단계!!!
1. Tokenizing/Lexing
Brekaing up a string of characters into meaningful chunks(Token)!
2. Parsing
Array of Tokens -> AST
3. CodeGen
AST -> Executable Code
js의 컴파일은 AOT 컴파일이 아닌 JIT 컴파일!!
자바스크립트도 대충 파싱하고 실행하는 과정을 따르는걸 예시로 보여주는데
이전 책을 읽었으면 당연하게 이해될것이다!!(아니 솔직히 왜 또 한말 또하는지 잘 모르겠따;;)
Compiler Speak
JS엔진에서 변수 처리(왼값, 오른값)
값이 할당될수있다면 왼값
(타겟 : 왼값)
student = [...]
for (let student in students)
getStudentName(73) -> 컴파일 타임에 처리된다
(소스 : 오른값)
for (let student in students) student 는 타겟이지만 students 는 소스
또한 student는 student.name ㅇㅔ 대해서는 소스다..
(c++ 에서 왼값과 오른값의 의미와는 다른것 같다 정말 타겟과 소스라고 말하는게 더 적절하겟따)
Cheating: Runtime Scope Modifications
non-restrict 모드에선 런타임중에 스코프를 치팅할수 있는 방법이 있다고 한다!!
물론 이 방법들은 지양되어야 하는게 옳지만.. 알아두자는 의미에서 써둔것 같다
첫번째 방법은 eval() 을 이용한 방식이다
요 방법 쓰는 안되는 이유론.. 이 함수 실행할때마다 컴파일이 일어나게 되서 성능측면에서 확실히 곤란해지게 된다!!!!
function badIdea() {
eval("var oops = 'Ugh!';"); console.log(oops);
}
badIdea(); // Ugh!두번째 방법은 with 키워드를 이용한 방식이다
var badIdea = { oops: "Ugh!" };
with (badIdea) { console.log(oops); // Ugh!
}어.. 이 방법도 컴파일타임이 아닌 런타임때 그런 스코프의 조작질이 일어나고ㅗ 이것 역시 위의 방법과 같은 이유로 성능저하를 일으킬 뿐만 아니라 가독성 측면에서도 좋지 않으므로 피하는게 좋다!!!
Lexical Scope
Lexical Scope ...
컴파일타임에 렉시컬 스코프가 대충 결정되기는 하지만 ..
그때 딱히 메모리 점유같은게 일어나진 않음.. 그런건 런타임때..
Chapter 2 Illustrating Lexical Scope
Marbles and Buckets and Bubbles... Oh My!
스코프란건 구슬과 양동이와 같다!!
*뭐... 엄밀히 따지자면 파라미터인 studentID는 블루스코프는 아니당
어디서 사용되느냐가 아닌 어디에서 선언되었나야 따라서 스코프가 결정됨
이 ㅁㅏ블 버킷 에서의 핵심!!
- 변수들은 특정스코프에서 선언된다 글고 요것들은 버킷 색깔에 맞는 마ㅡㄹ들로 생각될수 있따
- 섀도잉만 일어나지 않는다면 더 깊은스코프로가도 그 색깔로 칠해진다(원래 스코프의 색깔)
- 요놈들의 결정은 컴파일타임때 일어난다 이런 정보들은 변수들이 코드 실행중 찾기 위해 사용된다
A Conversation Among Friends
김 엔진(컴파일 과정의 시작~ 끝과정과 실행ㄹ과정에 책임이 있다)
박 컴파일러(엔진의 친구 파싱과 코드젠하는 더러욱 역할들을 다룬다)
이 스코프매니저(엔진의 친구 2 변수 식별자 등등등등을 모으고 이런놈들 접근규칙을 다룸)!!!!! 이놈들의 대화라고 생각해용~~~~
js가 어캐 동작한는지 알기 위해서 엔진의 입장에서 생각해봐야한다
You Don't Know JS Yet: Scope & Closures
var students = [
{ id: 14, name: "Kyle" }, { id: 73, name: "Suzy" }, { id: 112, name: "Frank" }, { id: 6, name: "Sarah" }
];
요런친구가있을때 저희는 걍 single statement라고 생각하겠지만 사실 엔진의 입장에선 그렇지 ㅇ않슴니당~~
컴파일러가 다루는 입ㅈ당~~
컴파일러가 요걸 보고 할일은 토큰으로 나누고 ast로 파싱하는 일을합니ㅏ다!!!
이 상태를 다루기 위한 컴파일러가 따를 스텝이 요깃슴니당
1. var students를 만납니당 컴파일러는 스코프매니저한테 그 스코프 버킷에 이 변수가 있나 물어볼거에요
그렇다면 컴파일러는 이 선언을 무시하고 쭉쭉ㅈ 갈겁니다.. 그렇지 않다면!! 컴파일러는 실행시간에 ㅋ스코프 매니저에게 스코프 버킷에 새로운 students 라는 변수를 만들거에용
2. 컴파일러가 나중에 실행을 위한 코드들을 만든ㄹ고.. 코드엔진은 스코프매니저한테 현재 스코프버킷에서 접근가능한 students라는 변수가 있는지 물어볼거에요 만역 없다면 엔진은 다른 데서 함찾아볼거에요 엔진이 변수를 찾는다면 어레이에 고놈의 레퍼런스를 집어넣어줄거에요
대화로 한다면 대충 이럴거에요
컴파일러: 이봐요 스코프 매니저씨!! 내강 stduents라는 형식선언을 찾았엉 들어본적있나유???!?
(전역)스코프매니저: 몰랑 만들어줄게
컴파일러: 스코프매니저씨 getStudentName 아심????
글로발스코프매니저: ㄴㄴ 방금 만듬
컴파: getStudentNameㅇ ㅣ 함수를 가리키는데? 새로운 스코프 버킷좀
뻥션스콥매니저: ㅇㅋ 여깃슴
컴: studentId아심?
뻥스매: ㄴㄴ 만듬
커: 여기 뽀룹잇음 ㅇㅅㅇ
......
엔진: 전역-스코프매니저씨 저희 시작하기 전에 getStudentName 좀 찾아주실?!??
글스매: 예아
엔진: 스매님 students 타겟이잇음.. 아심?
글스매: ㅇㅇ 여기 스코프에잇음
엔: ㅇㅋ undefined로 초기화햇음 써도됌 ㅋㅋ 근데 nextStudent 아심?
글스매: ㅇㅇ 여깃음
엔: ㄱㅅ undefined로 초기화 햇음 getStudentName 쏘스 레퍼런스 찾앗음 아심?
글스매 ; ㅇㅇ요기
엔: ㄱㅅㄱㅅ 함수네 실행시킬게욤 스매씨 우리 함수스코프 초기화해야함
...
두줄요약
컴파일러가 스코프 변수들셋업해두기
엔진들이 undefined로 초기화하기
허,,,미,,,, 두서없이 이리저리 쓰니 대충 이해는 되는데 남들에게 설명은 못할거같다
그냥 컴파일과정엔 컴파일러와 스코프 매니저가
실행과정엔 엔진과 스코프매니저의 적극적인 상호작용이 일어난다는게 요지인듯하다
Nested Scope
엔진이
< for (let student of students) { 문을 만난 경우>
엔: 뻥ㅇ스매님 students라는 소스가 잇는데 아심?
뻥스매: ㄴㄴ 담스코프에서 찾아보셈
엔: 글스매님 아심?
글스매: ㅇㅇ여깃슴
스코프를 다뒤지면서 찾아봤는데 없을땐 에러임!!!
하지만 이건 strict 모드에 따라서 다르게 처리될수잇음
소스면 Reference Error 던지기!!!
타겟 && restrict 모드면 ReferenceError 던지기!!!
여기서 주의할점은 not defined 와 undefined 의 차이점인데
undefined 는 변수가 존재하는거고 not defined는 변수가 정말 존재 x 인거임
영어의 문맥땜에 비슷하게 들리는거임 ㅇㅇ
어쩌다생낀 글로벌변수
엔진: 안녕 nextStudent 들ㅇ러본적 있니??
뻥스매: ㄴㄴ 담스코프한테 물ㅇ러보셈
엔진: 안녕 넌 아니?
글스매: 노노 노스트릭트모드니깐 만들어서 줄게 ㅋㅋ
(스트릭트 모드라면 레퍼런스 에러를 띄운다!!)
오피스빌딩 비유!!
비유좀 그만들어!!!!
그냥 대충요약
1층(현재스코프)부터 옥상(글로벌스코프)까지 찾는다!!!