현재 라이브러리는 label(String value)를 제공해요. 개정안에서는 이 메서드를 유지하면서 label(Integer value)를 추가하려고 해요.
이미 컴파일된 호출 코드는 계속 원래 시그니처를 지정해요. 반면 기존 소스의 label(null) 호출은 이 두 메서드를 대상으로 다시 빌드하면 모호해져요. 이 예에서는 어느 오버로드의 구현도 바뀔 필요가 없어요.
릴리스 안내에서 기존 바이너리를 유지하는 호출자와 소스를 다시 빌드하는 호출자를 구분해 주면 좋겠어요. 후자는 이전 의미를 유지하기 위해서라도 코드를 고쳐야 할 수 있으니까요. 어떤 마이그레이션 안내가 있어야 이 추가가 그 수고를 감수할 만할까요? 언제는 별도 메서드 이름을 쓰는 편이 기존 사용자를 더 배려하는 선택일까요?
이 두 메서드라면 우선 labelNumber(Integer value)로 이름을 나누겠어요. 기존 호출자에게 null마다 형변환을 넣으라고 하면 관련 없는 코드까지 수정 비용이 퍼져요. 이름을 공유해서 API가 정돈돼 보이는 것 외에 구체적인 이점이 없다면, 별도 이름은 라이브러리 쪽 수정도 작게 유지해 줘요.
호환성을 확인할 산출물을 명시해야 한다. 기존 선언을 대상으로 컴파일한 클라이언트 바이너리 하나를 보관하고, 그 소스는 별도의 재빌드 확인용 예제로 유지한다. 둘은 서로 다른 질문에 답한다.
유지된 호출 시그니처로 확인되는 것은 기존 바이너리가 어느 오버로드를 지정하는가이다. 해당 메서드 내부의 동작까지 같다는 뜻은 아니다. 구현 변경이 있다면 따로 검토하겠다. 이번 릴리스 판단에 유용한 근거에는 기존 바이너리 사례와 label(null)이 들어 있는 소스 사례가 모두 포함되어야 한다. 어느 한쪽 결과가 다른 쪽까지 설명한다고 해서는 안 된다.
이름을 나누면 다음에 수정할 사람에게도 단서가 남아요. labelNumber(null)은 어떤 연산을 의도했는지 보여 줘요. label(null)에 형변환을 넣어도 예전 메서드를 선택하게 할 수 있지만, 그렇다면 마이그레이션 안내에 그 형변환이 왜 필요한지 설명해 주면 좋겠어요. 그렇지 않으면 호출 코드를 정리하던 사람이 불필요한 장식으로 보고 지울 수 있어요.
여기서는 별도 이름을 기본 선택으로 삼는 것이 타당합니다. 다만 마이그레이션 안내에서는 여전히 두 의도를 구분해야 합니다. 기존 문자열 연산을 유지하려는 호출자는 label((String) null)을 쓸 수 있습니다. 새 숫자 연산을 의도하는 호출자는 숫자용 진입점을 써야 합니다. 둘 다 모호함을 없애더라도 서로 다른 수정입니다.
타입이 정해진 인수를 넘기는 호출자에게 공통 이름이 유용한 관계를 드러낼 때만 오버로드 제안을 유지하겠습니다. 그 경우 릴리스 안내에는 기존 바이너리에 관한 설명과 함께 영향을 받는 null 호출과 명시적인 수정 방법을 보여 줘야 합니다. 구체적인 용도로 그 관계를 설명할 수 없다면, labelNumber를 쓰는 편이 메서드 목록을 통일하려는 이유만으로 기존 호출자에게 소스 차원의 선택을 떠넘기는 일을 피합니다.
