LINUX.ORG.RU

История изменений

Исправление special-k, (текущая версия) :

Ну, прежде всего я рад, что у меня появляются фанаты, которые следят за моими постами, очень польщен, честно.

Не пойму как связаны monkeypatch и ORM (SQL вставка - это не monkeypatch, чтобы ты знал).

Кстати в руби не принято использовать monkeypatch.

Динамические возможности руби никак не связаны с monkeypatch (если ты об этом). Это называется метапрограммирование, и мне нравится метапрограммирование, я использую его постоянно, т.к. в ruby есть все для этого. И этого мне не хватает в других языках, например в js.

monkeypatch это небольшое изменение исходного кода, для удовлетворения насущных потребностей, кстати, тут один адепт питона говорил, что это нормально (изменить код в исходной библиотеке), так что по вопросам monkeypatch - к нему, он назвал это «обычный патч»))

Но, допустим, тебе нужно изменить функционал определенного класса, который не попал под делегирование, тогда, приходится расширять класс с помощью модуля(ей). При этом можно сделать красивую конструкцию для подобных задач, легко подключающую и отключающую изменения. Т.е. в ruby есть много инструментов, как раз приходящих из метапрограммирования. Например можно сделать hook метода вообще не изменяя его. И естественно все стараются обойтись без этого.

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

Сложно-ложно.

А главное, то, что перечислил TC отлично вписывается в возможности ORM. А рассуждать гипотетически можно сколько угодно.

Исправление special-k, :

Ну, прежде всего я рад, что у меня появляются фанаты, которые следят за моими постами, очень польщен, честно.

Не пойму как связаны monkeypatch и ORM (SQL вставка - это не monkeypatch, чтобы ты знал).

Кстати в руби не принято использовать monkeypatch.

Динамические возможности руби никак не связаны с monkeypatch (если ты об этом). Это называется метапрограммирование, и мне нравится метапрограммирование, я использую его постоянно, т.к. в ruby есть все для этого. И этого мне не хватает в других языках, например в js.

monkeypatch это небольшое изменение исходного кода, для удовлетворения насущных потребностей, кстати, тут один адепт питона говорил, что это нормально (изменить код в исходной библиотеке), так что по вопросам monkeypatch - к нему, он назвал это «обычный патч»))

Но, допустим, тебе нужно изменить функционал определенного класса, который не попал под делегирование, тогда, приходится расширять класс с помощью модуля(ей). При этом можно сделать красивую конструкцию для подобных задач, легко подключающую и отключающую изменения. Т.е. в ruby есть много инструментов, как раз приходящих из метапрограммирования. Например можно сделать hook метода вообще не изменяя его. И естественно все стараются обойтись без этого.

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

Сложно-ложно.

А главное, то, что перечислил TC отлично вписывается в возможности ORM.

Исходная версия special-k, :

Ну, прежде всего я рад, что у меня появляются фанаты, которые следят за моими постами, очень польщен, честно.

Не пойму как связаны monkeypatch и ORM (SQL вставка - это не monkeypatch, чтобы ты знал).

Кстати в руби не принято использовать monkeypatch.

Динамические возможности руби никак не связаны с monkeypatch (если ты об этом). Это называется метапрограммирование, и мне нравится метапрограммирование, я использую его постоянно, т.к. в ruby есть все для этого. И этого мне не хватает в других языках, например в js.

monkeypatch это небольшое изменение исходного кода, для удовлетворения насущных потребностей, кстати, тут один адепт питона говорил, что это нормально (изменить код в исходной библиотеке), так что по вопросам monkeypatch - к нему, он назвал это «обычный патч»))

Но, допустим, тебе нужно изменить функционал определенного класса, который не попал под делегирование, тогда, приходится расширять класс с помощью модуля(ей). При этом можно сделать красивую конструкцию для подобных задач, легко подключающую и отключающую изменения. Т.е. в ruby есть много инструментов, как раз приходящих из метапрограммирования. И естественно все стараются обойтись без этого.

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

Сложно-ложно.

А главное, то, что перечислил TC отлично вписывается в возможности ORM.