Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

表記の統一 #41

Open
3 tasks done
azu opened this issue May 19, 2014 · 12 comments
Open
3 tasks done

表記の統一 #41

azu opened this issue May 19, 2014 · 12 comments
Labels
Type: Feature New Feature

Comments

@azu
Copy link
Owner

azu commented May 19, 2014

書籍の用語の表記のぶれや説明の仕方にぶれがあるので、出来るだけ統一した書き方をする。

  • Promise

❌ Promises

Promiseという機能について言う時は大文字の単数を使う。

例外としてES6 Promisesの仕様へのリンクを貼る時はsをつけてもよい。

小文字は基本的にpromiseオブジェクトのみにする。

related #7

  • thenで登録するコールバック関数

thenで渡すコールバック関数の事

thenで登録するコールバック関数 という書き方を大体してるが、他の書き方の方が分かりやすいかどうか?

thenに登録するハンドラ?

thenで登録されたコールバック関数

という表記にする。

  • FulFilled または Rejected

いわゆるSettledの状態になった時という意味。
短縮しないで、毎回両方の状態について書いてる。

解決された時という書き方だと誤解を生みそうだし、Settledという言葉は馴染みがないので毎回書いてるが、より良い表現はないかどうか?

resolve または reject された時 という表現も使ってる。

どちらが主語になってるかの違いだけどどう統一しよう。


迷いそうな表記はCONTRIBUTIONファイルか何処かにまとめておく。

@azu azu added this to the 1.0.0 milestone May 19, 2014
@azu
Copy link
Owner Author

azu commented May 21, 2014

章、セクション

セクションって言葉は途中から使い始めた気がする。
どこかで混ざってそう

@azu
Copy link
Owner Author

azu commented May 22, 2014

事、こと

結構混ざってる感あるというか、IME的に統一して書くの難しい

@azu
Copy link
Owner Author

azu commented May 24, 2014

FulFilled または Rejected

💡 この用語の混乱する原因は

Promiseコンストラクタで(executor functionである)resolveが呼ばれた -> (promiseオブジェクトが)Fulfilledとなった -> onFulfilledが呼ばれる

という対象が途中で変わってる所にあるから、最初の説明にこの流れ自体をちゃんと書いてあげるのがいいと思う。

azu added a commit that referenced this issue May 24, 2014
@azu
Copy link
Owner Author

azu commented Jun 5, 2014

主語がPromiseの場合はresolve and reject
(Promiseがresolveした時)

主語がpromiseオブジェクトの場合はFulfilled and Rejected.
(promiseオブジェクトがFulfilledとなった時)


後、resolve(解決) と reject(棄却)としてるけど、
素直に成功と失敗に統一した方が直感的な気がする。

@azu
Copy link
Owner Author

azu commented Jun 5, 2014

resolve,reject / FulFilled,Rejected の表現

方針を決めたのでメモる(CONTRIBUTE.mdに入れておくべきかな)

resolve と reject の注釈
  • それぞれの用語の日本語の対応は resolve = 成功時 、 reject = 失敗時 とする。
  • resolveした時 ≠ 解決した時 としない(解決という言葉紛らわしいので避けるべき)
promiseオブジェクトが主語の場合
  • "promiseオブジェクトがFulFilled または Rejectedとなった時" と表記する
  • 必ず大文字で FulFilled とする
resolve,reject / FulFilled,Rejected の使い分け
  • "処理が成功した時" or "処理が失敗した時" という表現を使う場合、曖昧さが残らないように気をつける
    • 例えば、"処理が成功した場合はonFulfilledが呼ばれますが" というようにその結果についても触れる
  • new Promise の処理について述べるなら、"resolveした時" と書いてもよい。
    • "resolveされた時" とは書かない
  • thenでのメソッドチェーン等、new Promiseと直接関係ないケースの場合にはFulFilled,Rejectedを使う

例) Promise.raceは、promiseオブジェクトがどれか一つでもFulFilled または Rejectedになったら次の処理を実行します。

@azu
Copy link
Owner Author

azu commented Jun 5, 2014

https://github.com/azu/promises-book/blob/master/CONTRIBUTE.md

に表現についてを追加した。

@azu azu mentioned this issue Jun 6, 2014
15 tasks
@azu
Copy link
Owner Author

azu commented Jun 7, 2014

利用者、ユーザー

利用者 - ライブラリの利用者という感じで使う。
ユーザーよりも利用者の方がイメージがつきやすいので、利用者を優先する

@azu
Copy link
Owner Author

azu commented Jun 14, 2014

(promiseオブジェクトが)resolveされる は意味的には一応間違ってはないけど、
日本語的にはこっちのほうが使いやすくて面倒だなー

resolveされた -> その結果 -> promiseオブジェクトのstateがFulFilledとなる

Promise.all は、stateがFulFilledとなったのがキーとして反応するから、resolveされた時というのは多分違う。
けど、resolveされた時という表現自体は間違いではなくて、仕様でもそういう表現出てくる。

A promise is resolved if it is settled or if it has been "locked in" match the state of another promise.

https://github.com/domenic/promises-unwrapping#promise-objects

なので、resolveされたという表現は積極的ではないけど、使っても問題はない感じ。

@azu
Copy link
Owner Author

azu commented Jun 24, 2014

コミットメッセージについて特に何も決めてなかったけど、
conventional-changelog/CONVENTIONS.md at master · ajoslin/conventional-changelog のルールに大体したがって書いている。

write()という独自の記号を増やしてるけど…

ajoslin/conventional-changelog ベースのCHANGELOGを自動生成するために使ってるようなものなので、CHANGELOGに入れたほうがいいようなコミットはchoreではなくてfixを使ったほうがいいとかそれぐらいのイメージでやってる。

feat, write, fix, docs がたしかCHANGELOGにでるコミットの対象

@azu
Copy link
Owner Author

azu commented Jun 24, 2014

https://github.com/azu/promises-book/blob/master/CONTRIBUTE.md

にコミットメッセージを追加した

@azu
Copy link
Owner Author

azu commented Aug 29, 2014

Asciidoctor に依存した書き方を使っていい事を追記した

@azu
Copy link
Owner Author

azu commented Nov 20, 2016

https://github.com/azu/textlint-plugin-asciidoc-loose と textlintを使って簡単にはチェックしてる

@azu azu removed the meta label Jul 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature New Feature
Projects
None yet
Development

No branches or pull requests

1 participant