inline class 훑어 보기

[cwdoh]

inline class라는 것이 코틀린 1.3에서 소개되었다. 문득 발견하여, 의식의 흐름대로 적어보도록 한다.

• 일단 1.3 이상에서만 유효한 실험실(Experimental) 기능이다.
• 도입 배경은 KEEP 문서을 참조하자.

특징

• 단 하나의 프로퍼티만을 가질 수 있다.
• 인터페이스 상속은 가능하나 클래스 상속은 불가능하다.
• init 블록도 inner class도 가질 수 없다.
• 프로퍼티는 backing field를 가질 수 없어 lateinit, delegated prop. 역시 불가하다.
• 기본적으로 프로퍼티의 타입으로 인라인되며, 다른 타입으로 치환되어 사용되면 boxing 된다.
• 프로퍼티 타입으로 인라인되며 사용되는 이유로 시그니처 중복이 일어날 수 있으므로, 이러한 경우 메소드 명은 mangling된다. (즉, Java에서 사용 불가)

그래서

• typealias의 경우 말 그대로 동일한 type을 코드를 작성할 때 보다 가까운 의미로 별명을 지어 편리하게 관리할 수 있다.
• 반대로 inline class는 그 자체가 타입으로 인정된다.
• 즉, typealias는 type 체크에 대해 유연(?)하고 inline class는 그렇지 않다고 정의할 수 있다.

어디에 쓰면 좋을까?

• typealias는 확정되지 않은(?) 코드 형을 변경할 필요가 있거나, 주석 등으로 타입을 나타내는 대신 type에 대한 alias로 이를 선언하고 유연하게 사용할 수 있다. (라고 일단 우겨본다.)
• 그러나, 정의된 alias는 말 그대로 alias일 뿐이라 자연스럽게 assignable 하거나 유사 동작들이 런타임 오류를 발생할 수 있다, (물론 잘못 짠거다.)
• 이런 경우 inline class를 통해 명확하게 타입을 분리하되, 실제로는 inlining되어 성능상의 이슈가 없는(?) 깔끔한(?) 코드를 작성할 수 있을지도 모른다.

정말 그런가???

• 솔직히 boxing 여부 등이 구현 형태를 봤을 때 이해가 가지 않는 것은 아니나, 개발자에게는 straight 하지 않은 형태로 이해될 수 있을지도...
• method 명이 mangling되는 것은 비코틀린 JVM 코드와 협업할 때 치명적이다. 물론 숨기면 되기는 하지만...
• experimental은 맞고, 이게 정말 어느 정도의 사용성이 있을지는 대규모 access가 발생하는 시스템에서 비교적 안전하게 프로그램을 작성하고자 할 때 사용할 수는 있을 것 같기도 하다.

나머지는 나중에 다시 살펴보자.