IOが発生するメソッドをすべてasync化する #667
Conversation
|
とりあえず方針としては良いのかなと思いました！ |
| })?; | ||
| Ok(s) | ||
|
|
||
| pub async fn new(open_jtalk_dict_dir: impl AsRef<Path>) -> crate::result::Result<Self> { |
There was a problem hiding this comment.
newは同期処理を想像する人が多いと思います。個人的には妙な実装だな〜と感じます。must/should/want/canのmustとshouldの間くらいの気持ちです。
new_and_load_dicとかならまあ。
同じくらいの必須感があればこのままでも良いかなと！
Discordで他の人に聞いてもいいかも。
（この話以前結論出てましたっけ、出てたらすみません 🙇 ）
There was a problem hiding this comment.
長文を打っていたら内容が消失したので簡潔にすると、以下のような感じかと思います。
- Rustに限定すると「
newという名前でCPU/IO-boundな処理をするべきではない」という慣習は、私が知る限り無い。fallibleなnewもasyncなnewも世にありふれている。 - 他の言語だとそのような慣習はあるのか。「狭義のコンストラクタでI/O操作をしたらDIがやりずらくなる」みたいな理由くらいでは?
newとかNewとかみたいな名前でIO処理をしている例も結構あるのでは?
考えたり調べたりしてもよくわからなかったので、そのような原則について述べている書籍があれば知りたいと思っています。
There was a problem hiding this comment.
直感に反する実装は避けるというプログラミングの原則と、newは同期処理っぽいという自分の直感をもとにコメントした感じでした。
実際C#でasync newを実装するかでめちゃくちゃ議論されてるのを見かけました。
dotnet/csharplang#419
賛成多数だけど賛否両論で、たぶんasync newが許容される世界へ移行途中なのかなと感じました。
（個人的には、使うかどうかは置いといてとりあえず言語には実装したほうが便利なのではと思いました）
まあでも、たぶんユーザーがほしいのはblocking/nonblockingが選べるAPIでしょうし、ここはnewでも
async newでもどちらでも良いかなと思いました！
crates/voicevox_core_python_api/python/test/test_pseudo_raii_for_synthesizer.py
Outdated
Show resolved
Hide resolved
同期版は作りたいですね。実装は多分簡単なので、コード量が増えるのを許容できたらという感じだと思っています。 |
内容
IOを起こす次のメソッドを、
SynthesizerとVoiceModelの方に合わせてasync化します。UserDict::loadUserDict::saveOpenJtalk::new_with_initializeOpenJtalk::newOpenJtalk::use_user_dict#662 という話もありますが、統一性を保つ方を優先すべきかなと思いました。
関連 Issue
ref #545
その他