SmalltalkはどのようにMonkeypatchingを扱いますか？

Question

私はRubyコーダーです。私にとって、Monkeypatchingは、実行時に外部プロジェクトのクラスまたはモジュールメソッドを変更することです。私が興味を持っているのは、その素敵な機能の乱用からあなたを守るための、あなたがどのような仕組みを持っているかです。私が遭遇したいくつかのシナリオでは、Monkeypatchingが私に噛まれています。

スモールトークはまったく分かりませんが、その言語はRubyよりずっと前です。私はSmalltalkがこれらの問題のいくつかを解決したかどうかを調べるためにいくつかの調査を行ったが、Googleではあまり見つけられなかった。だからここで私は彼らの知恵を分かち合うことができればSmalltalkersを求めています。

シナリオA：バグ固定競合

プロジェクトAとBは、CプロジェクトCは、バグを有するプロジェクトに依存します。プロジェクトAとBのリリースにプロジェクトCの修正が含まれています。

コードでプロジェクトAとプロジェクトBが使用されている場合、どのようにしてパッチが競合しないのでしょうか？

シナリオB：

プロジェクトCを固定古いバグが彼らのプロジェクトの固定マイナーバージョンをリリースします。

プロジェクトAを読み込むと、パッチが適用され、破損する可能性がありますか？私は、コードが修正されている場合にパッチをロードしないなど、いくつかのメカニズムがあるかどうかを知ることに興味があります。

シナリオC：矛盾の拡張

プロジェクトAとBの利用プロジェクトCのFooクラス。両方ともFooにユーティリティメソッドを追加します。#toDateなど。 AのtoDateバージョンは日付文字列を返し、Bの1つはDateオブジェクトを返します。

両方のプロジェクト（C depを使用）を読み込むと、競合を警告/防止するメカニズムはありますか？または、メソッドの間違った期待のためにランタイムがエラーをスローするまで待たなければなりませんか？質問更新の答えを読む

について

、私は私の質問があまりにも広範かつ曖昧だった実現しています。だからここに書き直したバージョンです。

Answer 1

それは "ええ、それのために行く！

全体の考え方は、おそらくSmalltalkで最初に現れたでしょう。

クラスブラウザのルートクラスに移動し、好きな画像にすべてのメソッドを追加できます。

あなたは、コードとランタイムのセット全体が含まれてい画像を持っている（Smalltalkのようなだけで、他の一般的なものをAPLだった。）Smalltalkのは、他の通常の言語よりも、世界の非常に異なる絵を持っていること、しかし、覚えておいてくださいパッケージ。イメージを変更すると、イメージ内のコードのすべてのビットが影響を受けます。他の画像は変更されません。あなたはお気に入りのハックをリロードするためにセットを変更することができますが、基本的にコードをイメージにインポートしています。

Answer 2

Smalltalkersは「monkey patching」という用語を使用しませんが、「メソッドオーバーライド」が最も近い用語であると感じています。つまり、パッケージAのあるクラスのメソッドをパッケージBの同じクラスのメソッドでオーバーライドします。したがって、パッケージBをロードすると、Aの元のメソッドがオーバーライドされます。

メソッドオーバーライドには利点がありますが、慎重に使用しないと多くの不都合が生じるため、一般的には回避します。また、Smalltalkの方言にも依存しています。たとえば、VisualWorksでは、Squeakではない間にオーバーライドをサポートしています。

Answer 3

Smalltalkでは、従来、このオーバーライドを呼び出しました。 Smalltalkで使用するバージョン管理ツールに応じて、次のいずれかを行います。

• 質問

にクラス/メソッド（複数可）のオーバーライドを所有する新しいパッケージを作成元々質問

にクラス/メソッド（複数可）を所有しているパッケージの新しいバージョンを作成

VisualWorksとObjectStudio（私が最もよく知っているSmalltalk）では、後者のアプローチが使用されています。 Envyが使用されているVA Smalltalkでは、前者のアプローチが採用されています。私はSqueakがMonticelloを使った後者のアプローチに従うと信じていますが、私は完全には確信していません。

ほとんどのSmalltalkの実装では、オーバーライドされたコードの元のバージョンと現在インストールされているオーバーライドの両方を簡単に確認できます。

クライアントアプリケーションでは、オーバーライドは実際にvenor（またはSqueakチームなど）からSmalltalkの新しいバージョンに更新するときにのみ影響します。サーバアプリケーションでは、複数のアプリケーションがサーバに常駐する可能性があります。あなたが行うことをもっと慎重にする必要があります。

オーバーライド（または呼び出すとモンキーパッチ）は強力なツールですが、使用方法については注意する必要があります。使用する場合は、それらを必要とするかどうか再検討する必要があります定期的に。私のオープンソースのニュースアグリゲーターであるBottomFeederでは、私は最初に置いた多くの上書きを削除しました。自分自身に答える

Answer 4

は、ここでは、ビューの私の現在のポイントは次のとおりです。

シナリオAとB

すべてのコードが開いているので、ベストプラクティスは直接壊れたプロジェクトを修正するだろう。 gitのようなツールはすでにコードマージを管理しているので、ランタイムマージンに頼る必要はありません。それは必ずしも機能しません。

修正プログラムをマージして新しいバージョンをリリースする速度があるかどうかに応じて、Monkeypatchを生成することができます。その場合、最高の方法は、次のような仕組みを持つことです：

monkeypatch(ClassName, :method, &newcode) of the broken project 
is applied if project.version in [a set of releases where the bug exist] 
if the project version is unknown to the monkeypatch, 
    raise an error to tell the developer to fix the monkeypatch (check if bug exist). 
if a monkeypatch for that project, classname and method already exist, yell 

これは私の頭の上からです。バグ修正がメソッドの変更以上のものを必要とする場合、問題になる可能性があります。

シナリオC：TODO

Answer 5

あなたは最先端のソリューションを探しているなら、Changeboxesを見てみましょう。 Changeboxesの研究プロトタイプは、Squeak Smalltalkに基づいています。

を参照してください。http://scg.unibe.ch/research/changeboxes