Используя общие функции R, когда и почему?

Я разрабатываю основное обновление для R-пакета, и в рамках изменений я хочу начать использовать методы S3, чтобы я мог использовать общие графические, сводные и печатные функции. Но я думаю, что я не совсем уверен, что понимаю, почему и когда использовать общие функции в целом.

Например, в настоящее время у меня есть функция logLikSSM, которая вычисляет логарифмическую правдоподобие модели пространства состояний. Вместо использования этих функций я мог бы создать функцию logLik.SSM или что-то в этом роде, поскольку в R. существует общая функция logLik. Преимущество этого заключается в том, что logLik короче, чем logLikSSM, но действительно ли есть какой-либо другой момент в это?

Аналогичный случай, есть общая функция, называемая имитацией в пакете статистики, поэтому теоретически я мог бы использовать это вместо имитацииSSM. Но теперь описание функции симуляции говорит о том, что функция используется для "имитации ответов", но моя функция фактически имитирует скрытые состояния, поэтому она действительно не вписывается в описание имитации функции. Так что, вероятно, в этом случае я не должен использовать общую функцию правильно?

Прошу прощения, если этот вопрос слишком расплывчатый.

Ответ 1

Преимущества создания методов для генериков из ядра R включают в себя:

Простота использования. Пользователи вашего пакета, уже знакомого с этими дженериками, будут меньше помнить, что вам проще использовать ваш пакет. Возможно, они даже смогут сделать определенную сумму, не прочитав документацию. Если вы придумали свои собственные имена, они должны обнаружить и запомнить новые имена, которые являются дополнительным когнитивным бременем.
Использование существующих функциональных возможностей. Кроме того, любые другие функции, которые используют генерики, которые вы создаете, могут автоматически использовать ваши; в противном случае их пришлось бы изменить. Например, AIC использует logLik.

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

Что касается случая, когда ваша функция имеет совершенно другую цель, чем общий в ядре R, то это может быть более запутанным, чем полезным, поэтому вы можете в этом случае не создавать метод, а иметь собственное имя функции.

Возможно, вы захотите прочитать руководство по дизайну зоопарка (см. ссылку на zoo Design под Виньетками внизу этой страницы), в котором обсуждаются дизайнерские идеи, которые вошли в пакет зоопарка. К ним относятся обсуждаемая здесь идея.

EDIT: добавлены недостатки.

Ответ 2

Хороший вопрос.

Я разделю ваш вопрос на две части; здесь первый:

i] существует ли какая-либо другая точка в [создании функций generic]?

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

И из-за этой неопределенности этот шаблон проектирования (который называется перегрузкой на многих других языках) был инконирован и требует, чтобы R оценил класс объекта, а затем отправил этот объект соответствующему методу с учетом типа объекта.

Вторая часть вашего вопроса: [i] В этом случае я не должен использовать [общую функцию] правильно?

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

исходное тело функции заменяется кодом для выполнения диспетчеризации верхнего уровня, основанного на типе переданного объекта. Это заменяет исходный корпус функции, который просто скользит вниз на один уровень, так что он становится стандартным методом, который на верхнем уровне (общая) отправляет.

showMethods() позволит вам увидеть все те методы, которые вызывается новой созданной функцией отправки (общая функция).

Ответ 3

И теперь для одного огромного недостатка:

Простота MISUse: Пользователи вашего пакета, уже знакомого с этими дженериками, могут сделать определенную сумму без чтения документации.

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

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

Там была причина для статической компоновки и небольших исполняемых файлов в тот же день. Но теперь это поколение кода теперь получает деньги, отлаживая позже, если когда-либо, до того, как увольнения /IPO придут, не имеет памяти о днях, когда код действительно работал очень надежно, а установка/интеграция не требовали 200 $/час. Большие 4 консультанта или хакеры, которые проводят неделю, пытаясь получить и установить "простой" продукт с открытым исходным кодом и продуктивно работать.

Но если вы хотите продолжить традицию писать все более короткие имена функций/методов, будьте моим гостем.