On 12-07-02 10:53 PM, Simon Knapp wrote:
Hi,
I am a bit unsure about using imports in packages and have a few
questions. I'm sure the answer to some of these is 'it depends', but
I'm interested in what others think and 'best practices' when this is
the case.
1) If I use an import or importFrom declaration in a NAMESPACE, should
I also qualify the package in calls to the imported function (e.g.
maptools::readShapePoly)?
No, you won't need that. I would expect it to slow things down a bit,
since it needs two searches instead of one: look up "maptools", look up
"readShapePoly".
2) If the 'best practice' is to qualify the calls, when does one stop;
e.g. is it good/bad to say base::sapply?
3) If one is calling a (S3) generic, should one qualify the namespace?
Can this cause problems?
I think it wouldn't hurt other than the slight speed hit.
4) Is it better to check for arguments that are missing, or use a
default value of, say, NA; i.e. is missing(arg) preferable to
is.na(arg)?
That depends. It's easier to set an argument to a special value in a
call from another function than it is to conditionally set it to be
missing, but there are only a couple of general purpose choices for
"missing" values: NA and NULL, and you might want a user to be able to
specify those. (You can also use negative values for counts, etc., in
particular contexts.)
5) I would like to declare a (S3) generic 'cleanup(x)' but
'cleanup(...)' already exists in R.utils, which my package depends on.
Should I do it?
No. Use a different name. If you are using R.utils, your users are
also using it, and their code may want to call R.utils::cleanup without
the R.utils:: prefix.
6) I am used to writing 'requires(package)' for each package I use
within a function. If I have used import or importFrom in my
NAMESPACE, should I still do this?
No, it just slows things down, and can cause other problems for users
because it changes the search list.
Duncan Murdoch
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel