[Feature] 일관된 이름 짓기 규칙

[manudeli]

          @okinawaa @evan-moon 함수들 명명 규칙을 정해보면 좋겠어요. BREAKING CHANGE가 있기는 하겠지만 아직 사용량이 적을 때 명명규칙을 정하고 빠르게 BREAKING CHANGE를 내는 것도 장기적으로 도움이 될 수 있을 거 같아요

disassembleHangul, disassembleHangulToGroup도 disassemble로는 어떨까요? (BREAKING CHANGE 필요) Hangul이라는 맥락을 알필요가 있었다면 getSimilarityHangul이어야 하는지 아닌지 정의할 필요가 있을 거 같아요

disassemble(korStr, { type: 'string' }) // disassembleHangul
disassemble(korStr, { type: 'array' }) // disassembleHangulToGroup

Originally posted by @manudeli in #104 (comment)

[manudeli]

chosung이라는 것도 choseong이라는 함수로 변경하면 어떨까요? hangul은 표준이지만 chosung은 표준이 아닌것 같아서 표준대로 혹은 정해진 규칙대로하면 일관된 인터페이스를 만들 수 있을 것 같아요 좋을 것 같아요

http:https://roman.cs.pusan.ac.kr/result_all.aspx?input=%ec%b4%88%ec%84%b1

[okinawaa]

chosung이라는 것도 choseong이라는 함수로 변경하면 어떨까요?

동의합니다~ 바꾸면 좋을 것 같아요!

[manudeli]

@raon0211 서진님도 es-hangul 네이밍 규칙 같이 봐주시면 좋겠습니다

[okinawaa]

고민을 해봤는데요, es-hangul에서 import하는 함수들은 hangul이라는 단어를 제거하는것은 어떤가요?
개발자가 es-hangul을 사용한다면, 이미 충분히 hangul을 조작한다는 맥락은 알 수 있을 거라고 생각해요.

@evan-moon 님께서 남겨주신 코맨트에도 공감을 하지만,

import { disassemble } from 'es-hangul'과 같은 구문을 보면 "이 함수가 한글을 분해한다"라는 맥락을 파악할 수는 있겠으나, import 문의 특성 상 모듈의 최상단에 위치하여 함수가 소비되는 곳과의 거리가 멀 가능성이 높다는 점이 그 이유인데요.

한 파일의 라인수가 1000개 이하로 유지하는 개발자가 많고, 그 파일내에서 disassemble, getSimiliarty와 같은 함수들이 es-hangul에서 import되었다는 사실을 코딩하면서 까먹을것 같지는 않아요. 라이브러리는 개발자들이 편하게 사용할 수 있도록 추상화 해두고,
정말로 더 엄격하게 함수명을 정의하고 싶으신분들은, import의 as 로 aliasing을 처리하시는 방향을 추천드리는 것은 어때요~?

[manudeli]

chosung이라는 것도 choseong이라는 함수로 변경하면 어떨까요?

동의합니다~ 바꾸면 좋을 것 같아요!

현재 메이저 버전에서는 chosung에 deprecated jsdoc을 추가하고, choseong를 추가해 둘 다 제공하고 다음 메이저 버전에서는 chosung을 제거하면 좋을 것 같아요

[manudeli]

고민을 해봤는데요, es-hangul에서 import하는 함수들은 hangul이라는 단어를 제거하는것은 어떤가요? 개발자가 es-hangul을 사용한다면, 이미 충분히 hangul을 조작한다는 맥락은 알 수 있을 거라고 생각해요.

@evan-moon 님께서 남겨주신 코맨트에도 공감을 하지만,

import { disassemble } from 'es-hangul'과 같은 구문을 보면 "이 함수가 한글을 분해한다"라는 맥락을 파악할 수는 있겠으나, import 문의 특성 상 모듈의 최상단에 위치하여 함수가 소비되는 곳과의 거리가 멀 가능성이 높다는 점이 그 이유인데요.

한 파일의 라인수가 1000개 이하로 유지하는 개발자가 많고, 그 파일내에서 disassemble, getSimiliarty와 같은 함수들이 es-hangul에서 import되었다는 사실을 코딩하면서 까먹을것 같지는 않아요. 라이브러리는 개발자들이 편하게 사용할 수 있도록 추상화 해두고, 정말로 더 엄격하게 함수명을 정의하고 싶으신분들은, import의 as 로 aliasing을 처리하시는 방향을 추천드리는 것은 어때요~?

저는 hangul이라는 네이밍에 포함되는 것도 않는 것도 일관되도록 한 쪽으로 몰면 좋다고 생각해요. Hangul을 포함하면 맥락을 포함할 수 있다는 것이 좋다. 포함하지 않으면 짧은 함수명을 갖는 것도 라이브러리 사용시에 중요한 기분좋은 이유가 되어주는 것도 맞는 것 같아서 그것도 좋습니다. 단지 한 쪽으로만 몰면 좋겠습니다. @evan-moon 님 확인하고 문제없으면 어느쪽이든 진행하면 좋겠습니다

[crucifyer]

CHOSUNG 과 FIRST_INDEX 가 혼용되고 있던데, 이것도 통일하면 좋을 것 같아요~

[crucifyer]

chosung이라는 것도 choseong이라는 함수로 변경하면 어떨까요? hangul은 표준이지만 chosung은 표준이 아닌것 같아서 표준대로 혹은 정해진 규칙대로하면 일관된 인터페이스를 만들 수 있을 것 같아요 좋을 것 같아요

http:https://roman.cs.pusan.ac.kr/result_all.aspx?input=%ec%b4%88%ec%84%b1

https://www.unicode.org/charts/PDF/U1100.pdf
unicode.org 에서도 CHOSEONG, JUNGSEONG, JONGSEONG 이네요.

[manudeli]

chosung이라는 것도 choseong이라는 함수로 변경하면 어떨까요? hangul은 표준이지만 chosung은 표준이 아닌것 같아서 표준대로 혹은 정해진 규칙대로하면 일관된 인터페이스를 만들 수 있을 것 같아요 좋을 것 같아요
http:https://roman.cs.pusan.ac.kr/result_all.aspx?input=%ec%b4%88%ec%84%b1

https://www.unicode.org/charts/PDF/U1100.pdf unicode.org 에서도 CHOSEONG, JUNGSEONG, JONGSEONG 이네요.

의견과 참고할 자료를 주셔서 감사합니다👍

[Collection50]

#130 에서 말씀해주셔서 개인적인 의견 남겨드립니다 !

저는 아래와 같은 이유로 hangul이라는 표기가 붙여지는게 좋습니다 !

1. hangul을 생략하는 경우 불필요하게 축약되는 부분 존재
2. 불필요하게 축약되는 경우 네이티브 API나 서드파티 라이브러리와의 혼동

Example 1 - 기존 API를 사용하는 경우

// 비즈니스 로직 내에서 무엇을 `parse`하려는 것인지 헷갈림
const parse = () => {};

// 한글 파싱에 대해 직관적
const parseHangul = () => {};

Example 2 - 새로운 API를 생성하는 경우

// 말그대로 예시입니다.
// 한글 필터라는 것을 명시적으로 알리고 싶은데, hangul을 사용하지 않는 컨벤션으로 인해 불필요한 축약 발생
const filter = () => {};

// 네이밍에 대해 더 직관적으로 사용 가능
const filterHangul = () => {};

공식 문서에 존재하는 한글을 위한 모든 인터페이스를 제공하는 것을 목표합니다라는 목적에도 더 알맞다고 생각합니다 👍

[okinawaa]

@Collection50 님 좋은 의견주셔서 감사합니다!

[okinawaa]

hangul을 생략한다면, aliasing 하여 hangul을 붙히는 개발자가 더 많을 것 같고, hangul을 붙힌다면 굳이 축약하여 aliasing하는 경우는 많이 없을 것 같아서. hangul을 모두 붙히는것으로 결론지을게요.

hangul을 제거하기로 결정

논의에 참여해주신분들 다들 너무 감사해요. 특히 이슈레이징 해주신 @manudeli 님 이른 시기에, 라이브러리 함수 포맷을 결정 할 수 있게 해주셔서 감사해요.

[okinawaa]

@crucifyer 초성 중성 종성에 대해서는 다른 이슈를 만들어보겠습니다! 감사해요

[manudeli]

Contributing, PR템플릿과 같은 곳에 적혀 있으면 가이드하기 좋을 것 같아요