From h.wickham at gmail.com  Fri May 30 19:00:01 2014
From: h.wickham at gmail.com (Hadley Wickham)
Date: Fri, 30 May 2014 12:00:01 -0500
Subject: [Rd] Style question
In-Reply-To: <5388B803.8030506@fhcrc.org>
References: <CAOVYLHcgBqBmFMhSnx3hRELV4D9ijdHRoG=SmnRx8g=6f90F3A@mail.gmail.com>
	<538654A4.60402@fhcrc.org>
	<CABdHhvHP7VRmU6Z68EDieEPOsyqUkFRrkuG=ohO0f8V5J0tWUw@mail.gmail.com>
	<5388B803.8030506@fhcrc.org>
Message-ID: <CABdHhvE41f+cpngPjvXtCpbDiy68zBK-Qq-rQXt7c4ueW9FF=Q@mail.gmail.com>

> There is at least one subtle consequence to keep in mind when doing
> this. Of course, whatever choice you make, if the whatever() function
> moves to a different package, this breaks your package.
> However, if you explicitly import the function, your package will
> break at load-time (which is good) and you'll only have to modify
> 1 line in the NAMESPACE file to fix it. But if you do foo::whatever(),
> your package won't break at load-time, only at run-time. Also you'll
> have to edit all the calls to foo::whatever() to fix the package.
>
> Probably not a big deal, but in an environment like Bioconductor where
> infrastructure classes and functions can be shared by hundreds of
> packages, having people use foo::whatever() in a systematic way would
> probably make maintenance a little bit more painful than it needs to
> be when the need arises to reorganize/refactor parts of the
> infrastructure. Also, the ability to quickly grep the NAMESPACE
> files of all BioC packages to see who imports what is very convenient
> in this situation.

OTOH, I think there's a big benefit to being able to read package code
and instantly know where a function comes from.

Personally, I found this outweighs the benefits that you outline:

* functions rarely move between packages, and gsubbing for pkga:foo to
pkgb:foo isn't hard
* it's not that much hard to grep for pkg::foo in R/* than it is to
grep NAMESPACE

Hadley

-- 
http://had.co.nz/



[Rd] Style question
Hadley Wickham