openlang
타입과 데이터 모델링

측정 단위를 값싼 ID로 쓰기

이어지는 대화 1 ↓근거 살펴보기 ↓

정수 ID에 단일 케이스 유니온 대신 측정 단위를 써 보고 있는데, 더 퍼지기 전에 다른 의견을 듣고 싶어요. CustomerId of int는 [<Struct>]를 붙이지 않으면 할당이 생기고, 쓸 때마다 생성자나 매치를 거쳐야 해요. [<Measure>] type customerId로 하면 ID는 int<customerId>가 되고, 단위는 실행 시점에 지워지며, 고객 ID 자리에 int<orderId>를 넘기면 컴파일이 안 돼요.

지금까지 찾은 비용은 작지만 분명히 있어요. 단위는 숫자 타입에만 붙어서 문자열 ID는 여전히 유니온이 필요해요. 그냥 숫자로 되돌리려면 int id라고 쓰는데, 읽기엔 괜찮아요. 그리고 리플렉션 기반 JSON 직렬화기는 그냥 int로 보기 때문에 들어올 때 단위를 손으로 다시 붙여야 하고, 바로 그 자리에서 뒤바뀜이 끼어들 수 있어요.

내부 ID는 단위로, 바깥에서 값이 들어오는 가장자리는 유니온으로 나누면 어떨까요? 다음에 읽을 사람에게 그 구분을 설명할 만한 가치가 있는지는 아직 잘 모르겠어요.

이어지는 대화 1

서로의 근거를 따라
  1. 고유 링크

    단위는 통과시키고 유니온은 막는 게 하나 있어요. 바로 산술이에요.

    [<Measure>] type customerId

let a = 41<customerId>
let b = 1<customerId>
let c = a + b   // int<customerId>, compiles

    고객 ID 두 개를 더해도 타입 검사를 통과하고 세 번째 고객 ID가 나와요. a * b는 int<customerId ^ 2>가 되고요. 단위는 원래 양을 다루려고 만든 거라 평범한 산술을 전부 그대로 쓸 수 있어요. CustomerId of int는 누가 직접 정의하지 않는 한 +가 없고, let (CustomerId n) = id 같은 패턴은 숫자가 꺼내지는 자리를 눈에 보이게 해 줘요. 비교하고 넘겨주기만 하는 ID라면 저는 유니온 쪽으로 기울고, 할당 걱정은 [<Struct>]로 덜 것 같아요.

같은 질문의 다른 갈래

  1. 타입과 데이터 모델링

    Java에서 옮긴 헬퍼가 Groovy에서 다른 오버로드를 부른다

    Java 헬퍼 클래스를 빌드 스크립트 쪽 Groovy로 옮겼더니 같은 호출이 다른 메서드로 갔습니다. 순서대로 정리하면 이렇습니다. Java에서는 x의 선언 타입이 Object이므로 컴파일 시점에 show(Object)가 정…

    답글 3groovyjava
  2. 타입과 데이터 모델링

    빈 셀은 0과도 같고 빈 문자열과도 같다

    물려받은 매크로가 수량이 0인 주문 행을 표시하는데, 빈 행까지 전부 표시하더라고요. 검사 코드는 If ws.Cells(r, 4).Value = 0 Then이었어요. 빈 셀은 Empty가 든 Variant를 돌려주고, Emp…

    답글 7vba
  3. 타입과 데이터 모델링

    판별 유니온 전에 JSON 검증하기

    타입 단언은 컴파일러에게 이렇게 믿으라고 말할 뿐이에요. 외부 응답은 바이트로 시작하고, 누군가 확인하기 전까지는 그게 어떤 변형인지 알려 주는 게 하나도 없어요. 텍스트 디코딩과 JSON 파싱이 먼저 오고, 둘 다 각자 실…

    답글 9typescript