Как Smalltalk справляется с мартышкой?

Question

Я кодировщик Ruby. Для меня monkeypatching - это изменение во время выполнения методов классов или модулей во внешнем проекте. Меня интересует, какой у вас есть механизм, который защитит вас от некоторых злоупотреблений этой замечательной функцией. Далее следуют некоторые сценарии, с которыми мне приходилось сталкиваться, когда меня укусила мартышка.

Хотя я и не знаю Smalltalk, этот язык был там задолго до Ruby. Я провел небольшое исследование, чтобы выяснить, как и каким образом Smalltalk решил некоторые из этих проблем, но мало что нашел в Google. Итак, я спрашиваю Smalltalker'ов, могут ли они поделиться своей мудростью.

Сценарий A: конфликт исправления ошибок

Проект A и B зависят от проекта C. В проекте C есть ошибка. Релизы проектов A и B содержат исправление для проекта C.

Если ваш код использует проекты A и B, как вы узнаете, что исправления не будут конфликтовать?

Сценарий B: устаревшее исправление ошибки

Project C выпускает исправленную минорную версию своего проекта.

Если вы загрузите проект A, будет ли патч все еще применяться с потенциальной поломкой? Мне интересно знать, есть ли какой-нибудь механизм, например, чтобы не загружать патч, если код исправлен.

Сценарий C: конфликтующие расширения

Проекты A и B используют проект C класса Foo. Оба добавляют служебный метод в Foo, скажем, #toDate. Версия A toDate возвращает строку даты, а версия B - объект Date.

Если вы загружаете оба проекта (с помощью C dep), существует ли механизм, который будет предупреждать / предотвращать конфликт? Или вам придется ждать, пока среда выполнения выдаст ошибку из-за неверного ожидания в методе?

Об обновлении вопроса

Читая ответы, я понимаю, что мой вопрос был слишком широким и расплывчатым. Итак, вот его переписанная версия.

Answer 1

В Smalltalk мы традиционно называем это переопределением. В зависимости от инструментов контроля версий, которые вы используете с Smalltalk, вы можете либо:

• создать новую версию пакета, которому изначально принадлежал рассматриваемый класс / метод (ы)
• создать новый пакет, которому будет принадлежать переопределение рассматриваемого класса / методов

В VisualWorks и ObjectStudio (Smalltalk, с которым я наиболее знаком), используется последний подход. В VA Smalltalk, где используется Envy, используется первый подход. Я полагаю, что Squeak будет следовать последнему подходу, используя Монтичелло, но я не совсем уверен.

В большинстве реализаций Smalltalk легко увидеть как исходную версию переопределенного кода, так и установленное в настоящее время переопределение.

В клиентских приложениях переопределения действительно влияют на вас, только когда вы обновляетесь до новой версии Smalltalk от venor (или команды Squeak и др.). Для серверных приложений, где на сервере может находиться несколько приложений, вам нужно быть более осторожным в отношении того, что вы решили сделать.

Переопределения (или патчи обезьян, как вы их называете) являются мощным инструментом, но вы должны быть осторожны с тем, как вы их используете - и если вы их используете, вы должны повторно проверить, нужны ли они вам на постоянная основа. В моем агрегаторе новостей с открытым исходным кодом, BottomFeeder , я удалил много переопределений, которые я изначально установил.

Answer 2

Если вы ищете передовые решения, взгляните на коробки изменений. Исследовательский прототип Changeboxes основан на Squeak Smalltalk.

См. http://scg.unibe.ch/research/changeboxes

Answer 3

Smalltalkers не используют термин «исправление обезьян», но у меня есть ощущение, что «переопределение метода» - самый близкий термин. Таким образом, переопределите метод одного класса в пакете A, с методом того же класса в пакете B. Таким образом, когда вы загружаете пакет B, оригинальный метод в A переопределяется.

Переопределения методов имеют свои преимущества, но гораздо больше недостатков, когда не используются осторожно, поэтому в целом мы склонны избегать их. Это также зависит от диалекта Smalltalk - например, в VisualWorks инструменты довольно хорошо поддерживают переопределения, а в Squeak - нет.

Answer 4

Там написано: «Да! Иди!»

Вполне возможно, что сначала это понятие появилось в Smalltalk.

Перейдите в корневой класс в браузере классов, и вы сможете добавить все методы к изображению, которое вам нравится.

Помните, однако, что Smalltalk имеет совершенно другую картину мира, чем другие обычные языки (единственным распространенным языком, таким как Smalltalk, был APL). У вас есть изображение , которое содержит весь набор код и исполняемый пакет. Когда вы меняете изображение, это влияет на каждый бит кода в изображении. Другие изображения не изменены. У вас могут быть наборы изменений для перезагрузки ваших любимых хаков, но они в основном импортируют код в изображение.

Answer 5

Отвечая себе, вот моя текущая точка зрения:

Сценарий A и B

Поскольку весь код открыт, лучше всего будет исправить поврежденный проект напрямую. Такие инструменты, как git, управляют слиянием кода, поэтому нам не нужно полагаться на mergin во время выполнения, который не всегда работает.

В зависимости от желания апстрима объединить ваше исправление и скорость для выпуска новой версии, вы можете представить выпуск обезьяньего патча. В этом случае лучше всего иметь механизм, который говорит:

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