qwreey
2688409ebd
- use-after-destroy 검증 안전망: rbvm 영역/quad-debug 스코프 밖으로 최종 기각, Ref 사용 관례(useRef급 스코프) 명문화 - :With 동적 의존성: State immutable 가정과 모순되어 의도적 비지원 확정 - Operator 콤비네이터 카탈로그: 서브 에이전트 외부 리서치로 포함 범위/ 네임스페이스 이름 근거 보강(Clamp/Min/Max 추가 후보, 비트/비교/Sub/Div 드랍 후보, Debounce/Throttle 별도 질문으로 분리) - State 용어 정리 최종 확정(현재 이름 유지), Pipe 기각 근거·Compute vs Computed 네이밍 근거 문서화, :With와 Tag/Modifier clone 체이닝 혼동 방지 경고 추가 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VVG74qV2nQVykhvMRQW2UC
3.4 KiB
3.4 KiB
2026-08-12 스무 번째 세션 — State 이름 최종 확정, use-after-destroy 안전망 범위 재검토로 확정 기각
State 이름 확정
사용자가 용어 정리 라운드 1순위였던 State를 "그걸로 충분한듯"이라고
확정 — Computed/Derived 등 대안 검토 종료, 현재 이름 그대로 유지.
question.md 1번 절 반영.
use-after-destroy 검증 안전망 — 재검토 후 최종 기각
배경: 직전 세션(열여덟 번째)에서 이미 "고칠 필요 없음"으로 정리했으나, Claude가 그 문서에 "quad-debug로도 안 커버함"이라고 쓴 문장이 너무 강하게 들려 재확인을 요청했음. 사용자가 이 기회에 "정말 검토할 이유가 있는가"를 근본부터 재검토해달라고 요청, 구체적 근거를 제시.
사용자 논지:
- 제대로 된 use-after-destroy 검증은 (a) 등록된 모든 함수/클로저를
추적해
inst사용을 전부 조사하거나 (b)inst를 래핑해 이후의 읽기/쓰기를 가로채야 함 — 이건 quad가 손댈 문제가 아니라 Instance 가상화/추적을 전문으로 하는 rbvm 같은 라이브러리의 영역. quad가 이걸 재발명하면 그 자체로 오버엔지니어링이고, 필요하면 rbvm 같은 전문 도구를 병행해야 함 — quad 혼자 모든inst를 추적하는 건 못 함(Claude 동의). - quad-debug는 quad-base/quad-roblox 관점에서 quad 자신이 만들어낸
효과를 설명하는 유틸일 뿐 — 외부에서 Property를 셋팅하는 것 자체는
원래부터 관심사가 아님(
research/debug-tooling-plan.md"외부 변경 감지" 절이 이미 이 경계를 명시해뒀음을 Claude가 확인). - 실제로 use-after-destroy가 발생할 수 있는 자리는, quad가 이미
케어 안 하기로 확정한 요소들(Ref 등)이 정말로 외부로 반출되는
경우뿐 — 이미 권장 안 하는 패턴. Ref는 자식으로 넘기거나 본인이
쓰는 게 관례(React
useRef와 동급) — 이 관례가 문서에 명시적으로 적혀있지 않았다면 지금 적어달라는 요청. - quad가 세팅한
Tag/Attribute/Tween에는 더 자세한 전용 디버깅 유틸을 제공할 수 있음 — 모든 요소에Destroying을 Connect해서 범용 안전망을 만드는 건 동의 못 함, 그쪽 전용 디버깅에 투자하는 게 나음.
Claude 검토 결과 — 전부 동의. 추가로: Ref의 사용 관례("만든
컴포넌트 자신이 쓰거나 자식에게 넘김, 경계를 넘어 반출/전역 보관 안 함")가
base/bind-system-plan.md의 Ref 절엔 "얻어진 뒤 어떻게 쓰는지는 라이브러리
책임 범위 밖(사용자 자유)"이라고만 적혀있어 정작 그 관례 자체가 문서에
없었던 실제 갭이었음 — 이번에 명시적으로 추가.
반영
base/bind-system-plan.md: "Ref — 도입 확정" 절에 "권장 관례" 문단 신설 — useRef급 스코프 관례를 명문화, use-after-destroy가 발생 가능한 유일한 자리로 이 관례 위반을 지목.research/framework-comparison-findings.md: use-after-destroy 항목을 위 4가지 근거로 재작성(rbvm 위임, quad-debug 스코프 경계, Ref 관례 귀결, Tag/Attribute/Tween 전용 디버깅 투자가 낫다는 판단) — 결론(안전망 안 만듦)은 그대로, 근거가 훨씬 탄탄해짐..claude/question.md:State해소 표시 반영.