パブリックAPIのビルダースタイルについて再考する

[qryxip]

内容

Rust APIのJava APIでは現在ビルダースタイルを採用しており、systhesis系とttsおよびOnnxruntime::load_onceはsynthesizer.operate(required_params).optional_param(optional_param).exec()という形のAPIになっています。

var wav = synthesizer.tts(text, styleId).interrogativeUpspeak(false).execute();

let ort = Onnxruntime::load_once()
    .filename("./path/to/libvoicevox_onnxruntime.so")
    .exec()
    .await?;

これに対し、次の懸念があります。

tts()でTTSせず、そのあとのexecで実行されるのが違和感あります。
.ttsが返す値がすでにwavだとも読めるので、読んでる時に誤解しやすいコードになってるかも。

#907 (comment)

とりあえずの緩和として、"exec"の代わりに"perform"とすることを提案します。

 let wav = synth
     .tts("こんにちは", AMAAMA_ZUNDAMON)
     .enable_interrogative_upspeak(false)
-    .exec()
+    .perform()
     .await?;

これでJava APIおよびRust APIを公開してみて、わかりにくいという声が出なければこのissueを閉じる感じでよいと思ってます。

Pros 良くなる点

Cons 悪くなる点

実現方法

VOICEVOXのバージョン

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他

[qryxip]

#910

なんで.tts(..).option(..).exec()がfootgunではないと私が思ったのかというと、多分無意識に#[muse_use]の存在を前提に置いていた。

#909 のようなことを防ぐためにJava APIでも#[use_use]的なものを付けたいけど、残念ながらJavaのアノテーションにはそういうやつが無さそう…

[Hiroshiba]

無難な方に倒すと、.tts()がビルダーを返すことがわかるように.tts_task()や.configure_tts()などに改名するのが良いと思います！
ただJavaやRustで一般的なのであれば、.tts()でTTSされない形でも全然飲めると思います。

まあでも @qryxip さんが書いてくださった #909 のようなミスはかなり起こりやすいだろうなと思います。
Rustでは防げるならありだけど、まあ一般的に考えると流石に駄目かなーと。