「다형과 참조 배열」로 돌아가기
9. 선택 기준
| 데이터의 성질 | 사용하는 것 |
|---|
| 변종이 카탈로그이고 여러 곳이 같은 것을 가리킴 | 테이블마다 컬럼 하나, 각각 foreign. 3절이 이것을 선언 하나로 접으려 했고, 되돌렸습니다 |
| 값이 어느 테이블의 id이기만 하면 됨 — 행에 닿을 필요가 없음 | 검사 refs=A;B (참조가 내는 이름 §6) |
| 변종이 그 행에만 종속되고 id를 부여할 가치가 없음 | 다형 레코드(5절) |
| 원소 개수가 행마다 다르고 각 원소의 형태도 다름 | 다형 레코드 + 멀티 로우(5.3) |
검토 §5.2는 참조 경로로 한 벌 작성해 보고 실측한 다음에
값 임베딩을 판단하는 순서를 정했습 니다. 그 순서는 지켜졌지만 결론이 달라졌습니다 — 실측이
참조 경로를 되돌리는 근거가 되었고(참조가 내는 이름 §5),
값 임베딩의 판단은 6.1절이 구현 없이 마쳤습니다. 그래서 5절은 3절의 뒤가 아니라
그것만으로 성립합니다.
10. 담지 않는 것
| 무엇 | 근거 |
|---|
$value — 변종의 값을 한 셀로 압축 | 주 레이아웃 §7의 1차 판정 그대로 거부합니다. sep 표기와 중복되는 두 번째 방법이 됩니다 |
| 다단 상속 · 변종의 변종 | 5.1 |
| 한 테이블이 추상 타입 여럿의 변종이 되는 것 | $type의 답이 여럿이 됩니다. 요구가 실측되면 그때 정합니다 |
| 다형 레코드의 순환 | DSL §9.2 그대로 DAG입니다 |
다형 참조와 점 표기(Table.Field)의 혼용 | 다중 대상이 이미 거부하는 자리입니다 |
| DB 익스포터의 다형 레코드 매핑 | 변종마다 컬럼 집합이 다르므로 테이블 매핑을 새로 정해야 합니다. 5절 이후의 별건입니다 |
11. 단계와 게이트
| # | 무엇 | 형식 | 생성 코드 |
|---|
| 1 | abstract struct — 문법 · 모델 · 변종 목록. 필드가 없는 것까지 | 됨 — 무변경 | 됨 — 무변경 |
2 | 다형 참조 — 되돌렸습니다 | — | — |
2′ | 추상 타입의 표면 — 되돌렸습니다 | — | — |
| 3 | 참조 배열 — foreign X[] 거부의 해제. 대상 하나짜리까지 | 됨 — 무변경 | 됨 — 생성기 무변경. 접힌 연번 그룹과 같은 그룹으로 도달합니다 |
3′ | 대상이 여럿인 배열 — 표기가 없어졌습니다 | — | — |
| 4 | 다형 레코드 — $type, 컬럼의 합집합, 그리고 판별자 정렬(§6.3) | 됨 — 무변경. 기존 골든이 한 파일도 안 움직였습니다 | 됨 — 모든 언어. 7절의 표가 실제로 선 것입니다 |
| 5 | 다형 배열 — 멀티 로우 effects[].$type | 됨 — 무변경. 기존 24개 시나리오가 한 파일도 안 움직였습니다 | 됨 — 모든 언어. 접근자가 하나에서 목록으로 바뀌고, 원소 하나를 만드는 함수는 스칼라와 같은 것을 씁니다 |
| 6 | 변종의 Tombstone — struct X extends Y @N (removed). 멤버의 Tombstone과 같은 표기입니다(5.1.1) | 됨 — 무변경 | 됨 — 무변경. Tombstone은 어느 언어에도 나오지 않습니다 |
1~3이 형식을 건드리지 않습니다. 기존 골든이 한 바이트도 변경되지 않아야 하고, 변경되면
그 diff가 검토 대상입니다.
게이트가 판정한 것. 상속이나 합 타입이 있는 언어는 컴파일이 절반 이상입니다 —
변종 타입은 좁히기가 실제로 각 변종의 고유 멤버에 닿아야 뜻이 있고, 그것은 생성 코드에
대한 주장이라 컴파일러만이 판정합니다. 합집합을 평평하게 내는 생성기는 하네스를 빌드조차
못 합니다. 동적 언어(Python · Ruby · Lua · PHP)는 그것이 없으므로 파일을 읽고 행마다
클래스 이름을 확인합니다. Unreal은 UHT가 리플렉션이 이 타입들을 받아들이는지를
정합니다.
| 게이트 | 확인하는 것 |
|---|
| 기존 골든 | 무변경. 1~3은 새 표기를 추가할 뿐입니다 — 1·2단계에서 24개가 실측으로 무변경입니다 |
새 시나리오 variant-set | 지웠습니다. 2단계의 것이었고 그 단계가 되돌아갔습니다 (참조가 내는 이름 §6). 픽스처의 abstract struct Reward는 foreign Reward가 닿을 집합으로 있던 것이므로, 그 표기가 없어지면서 함께 사라졌습니다 |
| 1단계에 남은 게이트 | 단위 테스트뿐입니다 — SchemaParserTests · SchemaDeclarationsTests. abstract struct를 끝에서 끝까지 소비할 표기가 지금 없기 때문이고($type이 4단계입니다), 골든이 생기는 것은 4단계와 함께입니다. 1단계를 남겨 둔 이유가 그 4단계입니다 — 거기서는 상속이 실제로 있습니다 |
시나리오 array-foreign | 됨(3단계) — 거부 픽스처였던 것이 골든 트리가 되었습니다. 원소 3개 · 1개 · 0개인 행과, 참조의 두 형태를 모두 |
| 적합성 코퍼스 | 됨. owners 컬럼을 더하고 15개 하네스가 읽습니다. 생성기 결함 둘을 그 자리에서 검출했습니다 — Dart가 해석된 슬롯의 크기를 잡지 않아 로드에서 문제를 일으켰고, Unreal이 키 배열이 아니라 없는 멤버로 읽어 컴파일되지 않았습니다. 둘 다 접힌 연번 그룹에도 있던 것이고, 그쪽 게이트가 헤더만 보기 때문에 남아 있었습니다 |
| 이전 소규모 코퍼스 | 무변경. 그 선언이 없습니다 |
| 샘플 재생성 | RewardFixed의 대상 16개 목록이 선언 하나로 축소되는지 |
| 와이어 측정 | 됨(§6.1). 형식 개정 없음, 변종 16개까지 견딤, 그리고 행 순서가 1.9배를 가름 |
| Tombstone | 됨(6단계). 단위 테스트가 번호 예약을 판정하고 — Tombstone이 먼저 쓰였을 때와 나중에 쓰였을 때 둘 다 — 시나리오의 BurnEffect가 어느 언어의 어느 파일에도 나오지 않는지를 산출 트리 전수로 확인합니다. 「(removed)를 장식으로 읽는 빌드」는 모든 타깃에 이름을 남기면서 전부 컴파일되기 때문입니다 |
| 거부 | 8절의 9가지가 각각 그 셀 · 그 선언을 가리키는지 |