トップレベルのHTTP動詞メソッド(例: Faraday.get
)は、 default_connection
ivarにプロキシするmissing_method
を介して処理されるようです。 少し非効率的であることに加えて(確かに、通常のネットワーク要求の待ち時間と比較して小さな懸念です)、さまざまなツールで問題が発生します。
pry
、 solargraph
などのメソッドはオートコンプリートされません。この実装を明示的なメソッド定義に置き換えることはできますか?
こんにちは@dduugg 、メソッドを明示的に定義するのではなく、ドキュメントに適したソリューションを検討します。
接続でもメタプログラミング定義を使用します: https :
それはあなたが上で述べた点でうまく機能しますか?
その場合、 Faraday
モジュールについても同様のドキュメントスニペットを複製できます。
こんにちは@iMacTia 、返信ありがとうmethod_missing
コードに加えて、さまざまな@!method
および@!scope
ディレクティブを数えます) Faraday
提案しています。 しかし、それがここでの理論的根拠であるかどうかはわかりません(コードは書かれているよりもはるかに多く読み取られるので、コードライターの最適化はとにかくエラーだと思います)。
この変更で私を危険にさらした主な2つのポイントがあります。
delegates
を使用することがコードライターだけの利点だとは思いません。 私はRubyを何年も使用していて、他の人と同じように、この言語の簡潔な構文に感謝するようになりました。 いくつかのコードを読んでdelegates
を見つけたとき、それが何を意味するのかすぐにわかり、数十行のコードをほんの数行に凝縮する可能性があります。しかし、この変化に対する私の抵抗に焦点を合わせるのではなく、ここで紹介しようとしているどのような利点について話し合いたいと思います。 私はあなたが説明している問題を完全に理解しています、そして私は実際に可能であればそれを解決しようとすべきだと思います!
したがって、ここでの主な問題がコード提案、オートコンプリート、およびドキュメンテーションのためのIDE /ツールとの互換性である場合、私は単にドキュメンテーションコメントのような代替ソリューションを見つけることを提案しています(私たちはすでにYARDをかなり広範囲に使用しています)。
そして、この解決策が同じように冗長であると言うときもあなたは正しいですが、コメントはメソッドのリストほど読みやすさに影響を与えず、簡単に認識できると私は主張します。
こんにちは@iMacTia 、お返事ありがとう
def
が進むべき道だと思います)、前述のように、 method_missing
アプローチを置き換える必要があります。delegates
引数を理解できません。 Faradayは、HTTP動詞メソッドの処理に明示的な委任子を使用していないようです。 (この点での混乱は、HTTP動詞メソッドの実装が過度に複雑であるというコードの臭いである可能性があります)。delegate
などがコード作成者の助けになるということに同意する必要があります。 私は数十年のルビーの集合的な経験を持つ人々と協力していますが、ここでのアプローチに読みやすさの利点は見つかりませんでした(プライ、ヤード、シャーベット、ソーラーグラフを介してAPIを探索しようとして失われた時間を割り引いても) )。 少なくともこの特定の点で、ルビイストがこのAPIを初めて探索しようとするのを見る価値があるかもしれません。ここで正直な(そしてうまくいけば役立つ)フィードバックを提供しようとしているだけです。 OSSへのこの貢献に時間と労力を費やしてくれたことに今でも感謝しています。
ねえ、ファラデーのすべてのハードワークに感謝します! 私はこれが古い問題であることを知っていますが、発見可能性が少し問題であることに同意する傾向があります。 私はいくつかのミドルウェアに取り組んでおり、このセクションをREADMEに追加しました。 私の図書館は、これまでファラデーを使ったことがないかもしれない人を対象としているので、物事を説明するのは私の義務です。 私は(やや躊躇して)物事を困惑させるのは簡単ではなかったと言います。
@gurgeousドキュメントは間違いなく私たちがより良い仕事をすることができる前線であることに同意します(ファラデーのウェブサイトを立ち上げることでこれに取り組み始めましたが)が、この問題の提案があなたの特定のポイントをどのように解決するのかわかりません。
単に別の方法で作業することに慣れているため、要点を見逃しているかもしれませんが、ライブラリの使用方法がわからない場合は、オートコンプリートに依存せず、何をすべきかを推測します。
代わりに、ライブラリのドキュメントを確認し、それでも問題が解決しない場合は、コードを調べて、どのように機能するかを確認します。
したがって、改善されたドキュメント(ビジュアルまたはコード内)がこれを解決する方法であると私が考える理由。
しかし、おそらく私はここで何かを見逃しているのでしょうか、それともより良いドキュメントが役に立たない特定のユースケースを見逃しているのでしょうか?
「発見可能性」についての私の理解は正しいですか?
「発見可能性」についての私の理解は正しいですか?
私の場合ではありません。 私の期待は、特定の方法に飛び込みたい場合は、 pry
でls Faraday
し、続いて$ Faraday.get
などを実行できること
ご連絡いただきありがとうございます。
ファラデーのウェブサイトが大好きです! たぶん私はいくつかの提案でPRを提出することができますか? 喜んでお手伝いします。 こういう努力は、新参者にとっては常に報われると思います。 興味があれば教えてください。
pry
+ ls Faraday
、私もそのパターンのファンであり、広く使用しています。 method_missingから離れることは悪い考えではありません。 Ruby 3、言語サーバー、RBSなどの台頭により、Rubyは徐々にその方向に引っ張られてきています。しかし、これはドキュメントに次ぐものだと思います。
@gurgeousプルリクエストのドキュメントに興味があります。使用しているGitHubPagesにウェブサイトを公開するために使用されるGemfile(およびREADME)のセットを含むdocs/
ディレクトリを見つけます。 その使用法が不明な場合は、ウェブサイトの更新プロセスで、_that_のIssueまたはPRも開いてください。
ファラデーユーザーのことを気にかけてくれてありがとう!
ファラデーのウェブサイトが大好きです! たぶん私はいくつかの提案でPRを提出することができますか? 喜んでお手伝いします。 こういう努力は、新参者にとっては常に報われると思います。 興味があれば教えてください。
@gurgeous絶対に! 私たちのメンテナにとって明らかなことはユーザーにとってそれほど明白ではないかもしれないので、私たちは常にドキュメントやウェブサイトを改善するための助けを歓迎します。 さらに、私たちは本当に時間に苦労しており、それはしばしばドキュメントのコストがかかります。 実際、 @ olleolleolleの継続的な取り組みがなければ、ドキュメントははるかに悪い状態になります😄!
pry
ポイント(cc @dduugg)では、私はそれを使用したことがなかったので、おそらく理解できなかったのです。
追加の詳細を試してみたところ、 ls Faraday::Connection
は、動的に生成されたメソッドと委任されたメソッドが表示されていることがわかりました🙌。
したがって、この種のRubyの「魔法」を使用できないという私の当初の理解は間違っていました。実際、唯一の制限はmissing_method
ます。
私があまり好きではなかったのは、次のような明示的なメソッドの導入でした。
def self.get(...)
...
end
def self.post(...)
...
end
# ... and so on ...
しかし、動的な定義または委任をメインのFaraday
モジュールに追加することで、 pry
の検出を修正できれば、それで問題ありません。 初めて入手できなくてすみません!
時間の制約の心配はありません。 オープンソースのメンテナーであることを決して悪く感じないでください! 関係なく、あなたの努力に感謝します。 私も行ったことがあります...
同じページにいることを確認するために、ドキュメントに関するディスカッションを開始します。
@iMacTiaユーザーはFaraday::Connection
を調べることをどのように知っていますか? それ以来、検出可能なAPIを備えたHTTP gemに切り替えましたが、 https://lostisland.github.io/faraday/usage/をざっと見て、明示的に使用しているコード例はありません(最後の例ではそうしていますが)暗黙的に)。 これらの例は主にFaraday
で静的メソッドを呼び出しますが、pryにはありません。 このアプローチを採用している他の宝石は知りませんが、それでもアンチパターンであると考えています。
いつものように、私を聞いてくれてありがとう。