3

私は、私だけでなく多くの人に役立つと思われる Gem を開発しています。私が直面している問題の 1 つは、ネストされたハッシュをマージする必要があることです。それを達成するためにこの便利な Gistを見つけましたが、Gem で Hash# をこのように変更しても大丈夫かどうか疑問に思っていますか?

この種のコードを受け入れるか拒否するコミュニティの「標準」またはベスト プラクティスがあると確信しているので、SO にガイダンスを求めています。

ありがとうございました。

4

2 に答える 2

5

疑わしい場合は、サブクラスHash化してモジュールをサブクラスに含めます。メソッドをオーバーライドしたり、動作を大幅に変更したりする場合は、特にこれを行う必要があります。

Hashしかし、クラスを変更するだけではいけない理由がわかりません。たとえば、Rails は Core クラスを厳密に拡張しますが、誰かが文句を言っているのを聞いたことがありません。activesupportRailsがコア クラスを拡張する方法を見てみましょう。

https://github.com/rails/rails/tree/master/activesupport/lib/active_support/core_ext

gem のユーザーが望ましくない副作用を経験しないように、既存の動作を壊さないようにしてください。

于 2012-07-11T08:54:21.803 に答える
3

コアクラスを拡張するには、常に正当な理由が必要です。深いマージは十分な理由だと思います。深いマージのための新しい Hash メソッドを追加するにはHash#deep_merge- なぜですか。

しかし、それが既存のメソッドを変更することを正当化するとは思わない-Hash#mergeディープマージをサポートするためにオーバーライドする. 人々は、このメソッドが特定の方法で動作することを期待しており、gem を要求した後に突然異なる動作をする場合、気に入らないでしょう。やむを得ない場合は、ドキュメントの目立つ場所に記載してください。

更新：他の回答の下にあるコメントを読んでください。ええ、この場合の最善の解決策は、単に含めることですactivesupport/lib/active_support/core_ext/hash/deep_merge:)

于 2012-07-11T09:26:45.040 に答える