Объявите переменную final:
final ITraceable m_traceable;
Это гарантирует, что все потоки увидят присвоенное значение (при условии, что ссылка на this
небезопасно опубликована в конструкторе, которого здесь нет) .
Он говорит: «Да! Давай!»
Вся эта идея, вероятно, впервые появилась в Smalltalk.
Перейдите к корневому классу в браузере классов, и вы сможете добавьте все методы к изображению, которое вам нравится.
Однако помните, что Smalltalk имеет совершенно иную картину мира, чем другие обычные языки (единственным распространенным языком, подобным Smalltalk, был APL). У вас есть image , который содержит весь набор кода и исполняемый пакет. Когда вы меняете изображение, это влияет на каждый бит кода в изображении. Остальные изображения не меняются. У вас могут быть наборы изменений для перезагрузки ваших любимых хаков, но они в основном импортируют код в изображение.
В Smalltalk мы традиционно называем это переопределением. В зависимости от инструментов управления версиями, которые вы используете с Smalltalk, вы либо:
В VisualWorks и ObjectStudio (Smalltalk, с которым я наиболее знаком), используется последний подход. В VA Smalltalk, где используется Envy, используется первый подход. Я полагаю, что Squeak будет следовать последнему подходу, используя Monticello, но я не совсем уверен.
В большинстве реализаций Smalltalk легко увидеть как исходную версию замещенного кода, так и текущую установленную замену.
В клиентских приложениях переопределения действительно влияют на вас только тогда, когда вы обновляетесь до новой версии Smalltalk от Venor (или от команды Squeak и др.). Для серверных приложений, где на сервере может находиться несколько приложений, вам нужно быть гораздо более осторожным в том, что вы решите сделать.
Переопределения (или обезьяны, как вы их называете) - мощный инструмент, но вам нужен будьте осторожны с тем, как вы их используете - и если вы все же используете их, вам следует еще раз проверить, нужны ли они вам на регулярной основе. В моем агрегаторе новостей с открытым исходным кодом, BottomFeeder , я удалил множество переопределений, которые я использовал изначально.
Переопределения (или «обезьяньи патчи», как вы их называете) - мощный инструмент, но вы должны быть осторожны с тем, как вы их используете - и если вы все же их используете, вам следует еще раз проверить, нужны ли они вам на постоянная основа. В моем агрегаторе новостей с открытым исходным кодом, BottomFeeder , я удалил множество переопределений, которые я использовал изначально.
Переопределения (или «обезьяньи патчи», как вы их называете) - мощный инструмент, но вы должны быть осторожны с тем, как вы их используете - и если вы все же их используете, вам следует еще раз проверить, нужны ли они вам на постоянная основа. В моем агрегаторе новостей с открытым исходным кодом, BottomFeeder , я удалил множество переопределений, которые я использовал изначально.
Smalltalkers не используют термин «обезьянье исправление», но я чувствую, что «переопределение метода» - самый близкий термин. То есть переопределить метод одного класса в пакете A методом того же класса в пакете B. Поэтому, когда вы загружаете пакет B, исходный метод в A переопределяется.
Переопределения методов имеют свои преимущества, но гораздо больше недостатков, если их не использовать осторожно, поэтому в целом мы стараемся их избегать. Это также зависит от диалекта Smalltalk - например, в VisualWorks инструменты поддерживают переопределения достаточно хорошо, а в Squeak - нет.
Отвечая самому себе, вот моя текущая точка зрения:
Сценарии A и B
Поскольку весь код открыт, лучше всего было бы исправить сломанный проект напрямую. Такие инструменты, как git manage code, уже объединены, поэтому нам не нужно полагаться на объединение во время выполнения, это не всегда будет работать.
В зависимости от готовности апстрима объединить ваше исправление и скорости выпуска новой версии, вы можете представить себе обезьянью повязку. В этом случае лучше всего было бы иметь механизм, который говорит:
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
Если вы ищете передовые решения, обратите внимание на Changeboxes. Исследовательский прототип Changeboxes основан на Squeak Smalltalk.