Очистка списка функций в пакете R с большим количеством функций

Question

[Пересмотрено на основе предложения об экспорте имен.] Я работал над пакетом R, в котором около 100 функций, а может и больше.

Я хочу иметь, скажем, 10 видимых функций, и у каждой может быть 10 «невидимых» подфункций.

Есть ли простой способ выбрать, какие функции видны, а какие нет?

Кроме того, чтобы избежать 'diff', есть ли команда типа "all.equal", которую можно применить к двум разным пакетам, чтобы увидеть, чем они отличаются?

Answer 1

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

Обрезанная часть моих пакетов NAMESPACE:

useDynLib(qgraph)
export(qgraph)
(...)
importFrom(psych,"principal")
(...)
import(plyr)

, который соответственно загружает скомпилированные функции, делает доступной функцию qgraph(), импортирует из psych функцию principal и импортирует из plyr все функции, которые экспортируются в NAMESPACE plyr.

Для более подробной информации читайте:

http://cran.r -project.org / DOC / Инструкции / R-exts.pdf

Answer 2

Я думаю, что вы должны организовать свой пакет и кодировать так, как вам удобно;это ваш пакет в конце концов.NAMESPACE может использоваться для управления тем, что открыто или не открыто пользователю, как уже упоминалось другими, и вам не нужно документировать все функции, только основные вызываемые пользователем функции, добавляя теги \alias{} кфайлы Rd для всех функций поддержки, о которых вы не хотите, чтобы люди слишком много знали, или скрывайте их на справочной странице package.internals.Rd.

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

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

Answer 3

Ответ почти наверняка создать пакет. Некоторые эмпирические правила могут помочь в выборе дизайна:

• Пакет должен решить одну проблему
• Если у вас есть функции, решающие другую проблему, поместите их в отдельный пакет

Например, посмотрите на пакет ggplot2 :

• ggplot2 - это пакет, который создает прекрасную графику
• Импортирует plyr, пакет, который дает согласованный синтаксис и подход для решения проблемы разделения, применения, объединения
• Это зависит от reshape2, пакета с несколькими функциями, которые превращают широкие данные в длинные и наоборот.

Дело в том, что все эти пакеты были написаны одним автором, то есть Хэдли Уикхемом.

Если вы решили сделать пакет, вы можете контролировать видимость ваших функций:

• Только экспортируемые функции непосредственно видны в пространстве имен
• Вы можете дополнительно пометить некоторые функции ключевым словом internal, что предотвратит их появление в автоматически генерируемых списках функций.

Если вы решите разработать собственный пакет, я настоятельно рекомендую devtools и прочтение devtools wiki

Answer 4

Если ваш переформулированный вопрос касается «как организовать большие пакеты», то это может применяться:

• NAMESPACE позволяет очень тонко экспортировать функции: ваш пользователь увидит 10 видимых функций

• даже невидимая функция доступна, если вы или пользователи «известны», что делается с помощью оператора ::: тройного двоеточия

• пакеты бывают всех размеров и форм; Одно общее правило о том, «когда делить», может заключаться в том, что, как только у вас появится возможность использования в разных контекстах

Что касается diff на упаковках: а? Пакеты, как правило, не настолько близки, чтобы можно было использовать функцию сравнения. Команда diff действительно очень полезна для исходного кода. Вы можете использовать хеш-функцию в двоичном коде, если вы действительно этого хотите, но я все еще озадачен тем, почему это нужно.