function api 개편

[mrchypark]

class api 를 메인 유지보수로 두고, function api가 감싸는 형태가 되어야 할 듯.

[mrchypark]

두개 다 유지보수 할건지를 정해야 할 듯?

R6를 걷어내는 방향도 가능한데, 그렇게 하면 dbi 처럼 해야 할 듯.
모델 객체를 생성하고, tokenize 함수에서 제일 처음에 사용하는 식으로.

근데 이렇게 만들면 위에 작성한 것 처럼 r6 를 기본으로 하고 function 으로 감싸는 형태로 작성하기 어려움.

[mrchypark]

잘못생각했음. dbi 처럼 모델 객체를 사용하는 형태로 만들면 function을 먼저 만들고 r6를 감싸는 형태로 만들 수 있음.

[mrchypark]

또 잘못 생각했음. 기본값을 예쁘게 제공하기가 너무 어려움. function api는 모델의 설정을 지정할 수 있는 방법을 노출하되 단일 설정만 사용할 수 있도록 하는 것이 될 듯

[mrchypark]

#64

이거 진행하고 진행할 것.

[mrchypark]

단일 모델 객체만 있으니 싱글턴이라고 할 수 있는건가.

[mrchypark]

어휴 문서 상속이 function 에서 r6 method 로 안된다 ㅠ

반대는 되나?

[mrchypark]

cpp11 로 만드는 함수를 그대로 노출할 생각이 없었는데, 지금의 유지보수 동작의 쓸모없는 반복들을 확인하고 보니 cpp11 를 그대로 노출해서 function api를 만들고 그걸 사용해서 class를 다시 작성의 형태로 해야 할 듯.

이걸 바꿀 수는 없어서, cpp 코드를 그대로 사용하기 부분이 아마 유지보수가 좀 쉽지 않을까 싶은 생각이 들면서도,
결국 데이터 인아웃 맞추는 코드를 분리해서 두어야 나중에 리펙토링하기 좋겠다는 생각이 들었음.

[mrchypark]

지금해야 하는 것은 kiwi_bind에 출력 데이터 조정 코드를 추가하고, 노출하는 것으로 변경.

[mrchypark]

r-lib/cpp11#147

아놔 되는 줄 알았더니... 안되네 .

[mrchypark]

그럼 다시 정리해보면, kiwi cpp api가 있고 kiwi는 capi를 제공함.
cpp api는 class 스타일이고, c api는 function 스타일임.

그리고 cpp11은 function 스타일만 노출할 수 있음.

현재의 c api를 사용할 때의 장점은 class api를 모른채로 인아웃만 수정하면 됨. -> 유지보수 유리
단점은 c라서 콜백이라던지 다른 처리를 수행해야 함. -> 그게 나에게 읽기 어렵게 만드는데, 이제 레퍼런스가 생겨서 따라할 수 있게는 됨.

고치고 싶은 이유는 cpp11class 라는 식으로 패키지를 만들어 볼 수 있을 것 같아서 cpp class를 사용하는 형태로 작성하고 싶음.(이건 다른 이슈에)

어쨌든 지금 문제는 설명 문서를 한곳에서만 작성하고 싶은 것.