💡 만드는 법은?

URL: https://rust-analyzer.github.io/blog/2020/09/28/how-to-make-a-light-bulb.html

Title: How to Make a 💡?

IDE/LSP 서버는 (눈을 조금 찌푸려 보면) 웹 서버와 약간 비슷하게 동작합니다. “23번째 줄의 심볼 정의가 뭐야?” 같은 요청을 받아서, 언어 의미론에 따라 처리한 다음 응답을 돌려줍니다. 어떤 요청은 데이터 모델 자체를 수정하기도 합니다(“foo.rs 파일의 새 텍스트는 '…​'야”). 일반적으로, 어떤 두 요청 사이에서도 세계의 상태는 바뀔 수 있습니다.

이 점은 💡 기능과 관련이 있는데, 보통 이 기능은 두 번의 요청이 필요하기 때문입니다. 첫 번째 요청은 현재 커서 위치를 받아서 사용 가능한 assist 목록을 반환합니다. 목록이 비어 있지 않다면 편집기에 💡 아이콘이 표시됩니다.

두 번째 요청은 사용자가 특정 assist를 클릭할 때(또는 클릭하면) 이루어집니다. 이 요청은 해당 diff를 계산합니다.

두 요청 모두 사용자의 행동으로 시작되며, 그 사이에 임의의 이벤트가 발생할 수 있습니다. 따라서 assist는 list와 apply 동작 사이에 세계의 상태가 그대로 유지된다고 가정할 수 없습니다.

이로부터 assist를 위한 다음과 같은 인터페이스가 나옵니다(인텔리J의 IntentionAction를 약간 수정한 것):

1
2
3
4
5
interface IntentionAction {
  val name: String
  fun isAvailable(position: CursorPosition): Boolean
  fun invoke(position: CursorPosition): Diff
}

즉, 새 assist를 구현하려면 IntentionAction 인터페이스를 구현하는 클래스를 제공합니다. 그러면 IDE 플랫폼이 isAvailable과 getName을 사용해 💡 메뉴를 채우고, 사용자가 원할 때 invoke를 호출해 assist를 적용합니다.

이 인터페이스는 IDE 플랫폼 입장에서는 정확히 알맞은 형태지만, 구현하기에는 어색합니다.

대부분의 경우 isAvailable과 invoke의 시작 부분 코드는 비슷할 것입니다. PyCharm의 더 큰 예시는 isAvailable와 invoke를 보세요.

1
 2
 3
 4
 5
 6
 7
 8
 9
10
class RsIntentionAction<Ctx>: IntentionAction {
  fun getContext(position: CursorPosition): Ctx?
  fun invoke(position: CursorPosition, ctx: Ctx): Diff

  override fun isAvailable(position: CursorPosition) =
    getContext(position) != null

  override fun invoke(position: CursorPosition) =
    invoke(position, getContext(position)!!)
}

중복은 다소 무식한 방식으로 제거됩니다. isAvailable과 invoke 사이의 공통 코드를 (assist별) Ctx 데이터 구조로 구체화(reify)하는 것입니다. 이 방식은 목적을 달성하긴 하지만, (그저 이것저것 담는 주머니에 불과한) Context 타입을 정의하는 일이 번거롭습니다. 예를 들어 InvertIfIntention.kt에서 이를 확인할 수 있습니다.

rust-analyzer는 제가 느끼기에 약간 더 나은 패턴을 사용합니다. IDE와 웹 서버를 비교했던 원래의 비유를 떠올려 봅시다. 이를 더 확장해 보면, assist는 HTML 폼과 비슷하다고 말할 수도 있습니다. list 동작은 폼을 다룰 때의 GET에 대응되고, apply는 POST처럼 보입니다. HTTP 서버에서도 GET /my-form과 POST /my-form 사이에 세계의 상태가 바뀌기 때문에, HTTP 서버 역시 데이터베이스를 두 번 조회합니다.

Django 웹 프레임워크에는 이를 구현하기 위한 멋진 패턴이 있는데, 함수 기반 뷰(function based views)입니다.

1
2
3
4
5
6
7
def my_form(request):
  ctx = fetch_stuff_from_postgres()
  if request.method == 'POST':
    # apply changes ...
  else:
    # render template ...

하나의 함수가 GET과 POST를 모두 처리합니다. 공통 부분은 한 번만 처리하고, 차이점은 if의 두 분기에서 처리하며, 런타임 매개변수가 if의 어느 분기를 선택할지 결정합니다.

이 패턴을 파이썬 웹 프레임워크에서 러스트 IDE로 옮기면 다음과 같습니다:

1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
enum MaybeDiff {
  Delayed,
  Diff(Diff),
}

fn assist(position: CursorPosition, delay: bool)
    -> Option<MaybeDiff>
{
  let ctx = compute_common_context(position)?;
  if delay {
    return Some(MaybeDiff::Delayed);
  }

  let diff = compute_diff(position, ctx);
  Some(MaybeDiff::Diff(diff))
}

Context 타입은 로컬 변수들의 집합으로 녹아들어 사라졌습니다. 또는 동치로 말하면, Context는 제어 흐름(control flow)의 구체화입니다. 즉, if 이전에 살아 있는(live) 로컬 변수들의 집합입니다. 이 패턴을 코루틴/제너레이터/async로 구현하고 싶을 수도 있지만, 실제로는 고정된 중단(suspension) 지점이 하나뿐이므로 그럴 필요는 없습니다.

단순화되지 않은 예시는 invert_if.rs를 참고하세요.