qwreey
17a2e4f05f
세 건을 한 커밋에 처리:
1. ui-shorthand-plan.md — Tween 지원 확정. 숏핸드가 자식 프로퍼티를 직접
대입하지 않고 Dispatch.process(child, prop, ..., 1)로 위임하면 Tween이
공짜로 따라옴(해석 코드는 PropertyHandler 하나에만 남음). "process 중
inst를 바꾸는 건 키를 바꾸는 것과 같은 층위라 UB 아님"을
dispatch-core-plan.md에 일반 규칙으로 명문화. wrap을 Tween<T>.Value에만
적용되도록 들어올리는 헬퍼가 새로 필요한 유일한 부품. ROADMAP M10에
통째로 빠져 있던 UI 숏핸드 항목도 보강.
2. existing-instance-bind — 기각, research/ → archive/. 사유: Length/Offset
등 quad가 만든 트리를 전제한 부기를 바깥에서 밀고 당기는 버그 표면이
치명적으로 넓어짐. "열려 있음"을 전제로 쓰인 본문 7곳도 같이 정정
(architecture.md의 "아직 미정" 절은 유일 항목이었어서 절 자체를 갱신).
3. bind-system-plan.md 3단계 분할 + store-semantics.md 흡수(순수 이동):
- base/store-plan.md 신설 — Store = 이름 붙은 Source 모음
- base/source-state-plan.md 신설 — 반응형 코어(Source⊇State, 전파 모델,
:With/:Compute/:Apply/previous, Observer, 구독·생명주기 게이트)
- bind-system-plan.md 1238→203줄(인스턴스 생성·이벤트 네이밍 + 색인)
- store-semantics.md 삭제
참조 40여 곳 스윕. doc-check.py ERROR 0, WARN 101→84.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5.2 KiB
[역전됨] StoreSource 프록시 설계 — Source가 State를 만족하는 서브타입으로 대체됨
역전 일시: 2026-08-06 (세 번째 세션). 원 확정 일시: 2026-08-04
(component-composition-plan.md 컴포넌트화 논의 3~4번 항목).
현재 유효한 설계: base/source-state-plan.md의 "Source가 State를
만족함 — 구조적 서브타입" 절이 최종 소스. 이 파일은 더 이상 능동적으로
참고할 필요 없음(구현에 안 씀) — 왜 이 경로를 갔다가 되돌아왔는지가
quadnomicon(프레임워크 설계자용 심화 콘텐츠, research/documentation-plan.md
0번 항목) 소재로 가치 있어서 사유·원문을 통째로 보존해둔 것.
역전된 사례 — 원래 무엇을 확정했었나 (2026-08-04 원문)
store.key로 값을 얻을 때, Store가 내부 Source 객체를 직접 노출하지
않고 별도의 얇은 프록시 타입 StoreSource를 만들어 반환하는 설계였음:
Source = 인터페이스이자 구현체: 독립 생성자
Source(initial)가 기본 구현체,store:GetSource("key")(가칭)류 접근자가 반환하는 값은 같은 인터페이스를 구현하는 별도의 얇은 프록시(StoreSource) — 읽기는store.key로, 쓰기는store.key = v로 위임. 내부 Source 객체를 그대로 노출하지 않음 — 그러면 "쓰기는 오직 Store의__newindex뿐"이라는 기존 확정과 새 쓰기 경로가 충돌하게 됨.캐시 안 함: State가 이미 "매번 새로 만듦, store에 캐시 안 됨"으로 확정돼 있어 일관성 + 엔지니어링 비용 둘 다 이쪽이 쌈 — 사용자 확정 ("그냥 엔지니어링적으로 비용이 싼거 택해").
같은 논의에서 파생된 핸들러 계약 쪽 결정도 같이 뒤집힘 — Source를 핸들러가 직접 받을 때는 별도 유니온 타입으로 처리하기로 했었음:
핸들러가 값을 받을 때
Source<T> | State<T>유니온으로 받고, 내부에서 타입 체크만 하면 됨(Source면 인스턴스 변경 이벤트에 걸어 역방향 쓰기까지 처리, State면 읽기만) —isHandlable/priority/process/retract4종 계약에 5번째 항목을 추가할 필요 없음.
역전된 이유
store.key의 타입 문제를 다시 들여다보다가 드러남: Store의 정적 타입을
{key: State<number>}류 평범한 레코드 타입으로 지으면(2026-08-04 3차
라운드에서 확정했던 방식) Luau 구조적 타이핑상 그 필드의 읽기/쓰기 타입이
같아야 하는데, 실제 쓰기(store.key = value, raw number)와 읽기
(State<number>)가 서로 다른 타입이라 애초부터 정합적이지 않았음 —
StoreSource 프록시 설계 시점엔 이 비대칭을 못 잡았던 것.
이걸 풀려고 대안(store를 store.key/store.state.key로 네임스페이스
분리하는 안, RefSource<T>라는 store 전용 타입을 새로 만드는 안)을
검토하다가, 더 근본적인 재구성으로 수렴: Source 자체가 구조적으로
State를 만족(Svelte Writable<T> extends Readable<T>와 같은 모양)
하게 만들면,애초에 "Source를 감추고 별도 프록시로 감쌀" 이유 자체가
없어짐 — Store가 내부에 갖고 있는 진짜 Source 객체를 그대로 돌려줘도
안전하고, 오히려 프록시 객체를 매번 만들거나 캐싱하는 계층 하나가 통째로
사라져서 더 쌈.
이전 것과 지금 것의 차이
StoreSource(역전됨) |
Source가 State를 만족(현재) | |
|---|---|---|
store.key가 반환하는 것 |
별도 프록시 StoreSource(Source 인터페이스를 구현한 wrapper) |
진짜 Source<T> 객체 그대로 |
| 쓰기 문법 | store.key = value(__newindex) |
store.key:Set(value) |
| 캐싱 | "매번 새로 만듦"(State와 같은 정책) | Store 생성 시 이미 만들어둔 Source를 그대로 반환 — 별도 캐싱 메커니즘 자체가 불필요 |
| 핸들러가 Source를 받는 방법 | Source<T> | State<T> 명시적 유니온 |
State<T> 하나만 받아도 서브타입 호환으로 자동 통과, 런타임에 구분하고 싶으면 isSource류 판별자 |
| 타입 정합성 | 레코드 필드 읽기/쓰기 타입 비대칭 문제가 잠재해 있었음(발견 안 된 채로 확정됐었음) | 필드 타입이 항상 Source<T>로 대칭 — 쓰기가 메소드 호출로 옮겨가며 문제 자체가 해소됨 |
왜 완전히 헛수고는 아니었나
StoreSource가 짚었던 문제의식(Store 내부 표현을 그대로 노출하면 안
될 수 있다, Source와 State는 다른 쓰기 권한을 가져야 한다)은 여전히
유효함 — "State/Source 경계 규칙: 파생이면 읽기전용, 원본이면 쓰기 가능"
원칙(base/component-composition-plan.md 2번)은 살아남았고, 결론만
"별도 프록시 타입을 만든다"에서 "Source 자체를 서브타입으로 승격한다"로
바뀐 것. 이 반전 자체가 "타입이 없던 v1 습관을 재검토 없이 typed 재작성에
그대로 가져오면 안 된다"는 더 큰 교훈의 구체적 사례이기도 함(사용자 회고,
base/source-state-plan.md 참고) — quadnomicon에서 "설계가 왜 이렇게
반전됐는가" 사례로 쓰기 좋음.