FINEARCHS

シーケンス的なもの＝JSのiterableみたいなものですかね？ それならシーケンス的なものにもれなく`.choise`などを継承させるやり方の方が私としては好みです チェインさせやすいですし、イメージ的にこれらの関数は乱数よりも配列が主体なように思います まあエイリアスとして両方用意してもいい気がします

> 他の言語でも`rand.choice(seq)`の形式が多いように思います あら、そうですか？python以外ではあまりイメージがないですが、事例があれば教えて下さい。 > 各シーケンスの内部実装に依存させるのではなく汎化されたインターフェースを通じて処理する方針です その点では、各シーケンス的なものの上位クラスで定義されたメソッドを下位でそのまま受け継いでも独自で拡張してもよいようにした方が柔軟性が高くなると思います。

> 調べた範囲ではchoice相当の関数が明確に配列側に所属しているのはRubyとSwiftだけでした。 確かにそうみたいですね… > シーケンスごとの実装に任せるということは乱択アルゴリズム自体を任せてしまうということなので、等価なシーケンスでも結果が変わってしまう可能性があります。 任せるのではなく変えてもよいとする余地を作るのが継承です。 多くの場合は共通のアルゴリズムを使うのがよいでしょうが、シーケンスの仕組み次第では既存の仕組みが非効率になってしまうこともあるでしょう。

> 選択アルゴリズムを具体的に指定しない限り結果の一貫性を保つのは難しいです。 元になるシーケンスの仕組みが違うのに結果に一貫性を持たせる必要性は薄いように思います。 どうしても結果に一貫性を持たせる手段を用意したいというのであればやはり`rand.choise`も`arr.choise`も両方用意するのが妥当かと思います。 > 結果を変えずに、乱択の段階で行う必要のある最適化が思いつきません。 抽象化されたシーケンスには長さが無限になるものもあると思いますが、そのようなシーケンスは通常のアルゴリズムで乱択すると時間が無限にかかってしまいます。 > 要するに基本的な対象である組み込み値にあれこれ生やしすぎたくないという気持ちです。 むしろ基本的な対象こそ様々な機能を生やして便利にすべきでは？だからこそこれまで組み込みプロパティを増やす方向で進めてきていたものと思っていましたが > 単にチェーンの形式で書きたいというだけなら[UFCS](https://ja.wikipedia.org/wiki/Uniform_Function_Call_Syntax)のような糖衣構文を導入する方が健全なように思います。 それは以前からやりたいと考えていましたが、要するに組み込みプロパティをユーザー側でも定義できるようにするということですから健全性の観点でいうと特にメリットはないのではと思います。

まあ色々ありますが、それら全てをひっくるめてもチェインの形で書けるメリットが上回ると思います。 ネストが増えるのは悪です。

> ArrayListかLinkedListかのような内部実装が結果に影響するのが良いとは思いません。気軽に変更できてほしいです。 （全員で同じ問題をする日替わりゲーム等がリファクタリングで違うものが出てくると困るので） 確かにその点だけ見るとプラスマイナスでいえばマイナスでしょうが、マイナス幅は小さいと思います。 日替わりゲームの例で言うなら、そもそもリファクタリングするのにアルゴリズムが変わらない場合のほうが少ないのではないでしょうか？ > 有限か無限かは停止性にも関わってくるので最適化というより根本的なアルゴリズム自体が変わると思います。 いくつか他言語の実装を見ましたが、有限でランダムアクセス可能なもの(≒配列)のみを対象にしていました。 アルゴリズムが異なっていても、例えばchoiceなら「シーケンス状のものから乱数番目の要素を取得する」という共通部分を持った動作が同じ名前で呼び出せるというのは直感性・学習容易性において大きなアドバンテージになると考えられます。 また、これはもっと早く言及すべきでしたが、AiScriptは他の言語の真似をするために作られた言語ではないはずですから、他言語を参考にするのはそうしなければ天秤がどちらにも傾かないような場合のみに限るべきではないでしょうか？ > 個人的には1オブジェクトの責任は小さくあってほしい主義です。（プロジェクト自体の方針は把握してませんが……） > ただの関数をメソッド呼び出しのように書けるようにするものなのでプロパティに追加して所属させるのとは別物です（是非は別として）。 着火した身でいうのもアレですが、本筋にあまり関わらなそうなのと長文しか出せない気がするのと論点を絞りたいのとでこの場では返答を割愛します。（また機会があれば・・・）

関数にバグやパフォーマンス上の問題があった時に自力救済ができるというのと、 ユースケース次第では一部の関数の使用を禁止したい場合があるかもしれないので、そういう場合にメッセージを出す関数で上書きするなどの処置が取れるといいかなと思っています

同パッケージ内でも、ファイルを分けてお互いに参照しない状態にすればtree-shakingは効きましたっけ？

codecovのv4で（基本的に）トークンが必須になった周りの問題っぽい？ https://github.com/codecov/codecov-action/issues/1274

いや、正直見当がつかないですね…