Hi Kasper FWIW, the package development and maintenance support in 'mvbutils' makes it trivial to work with namespaced packages, even at the earliest stages of development. It's completely easy to add and remove functions to/from the namespace (and the exported visible bit) while the package is loaded. Debugging is seamless (via the 'debug' package, anyway). There is no need to re-load the sources or rebuild the package when you make changes-- the source version and installed version all get updated automatically. I've done a namespaced-package-from-standing-start in under 10mins, and could probably shorten that if a beer was at stake. I've also forced a few colleagues to build packages this way, and have had positive feedback. Of course, to get all these wonderful things, you do have to somewhat buy in to 'mvbutils' way of working. But that's not necessarily a bad thing ;) For me, it's definitely been preferable to build in the namespace from the start, because otherwise additional errors can appear when functions become "unexported". Namespaces really do clarify things and avoid the search-order problems, so the key thing is just to make sure the development cycle is easy when namespaces are involved. bye Mark Mark Bravington CSIRO CMIS Marine Lab Hobart Australia
From: r-devel-bounces at r-project.org [r-devel-bounces at r-project.org] On Behalf Of Kasper Daniel Hansen [kasperdanielhansen at gmail.com]
Sent: 07 July 2011 00:06
To: Duncan Murdoch
Cc: Prof Brian Ripley; R-devel at r-project.org
Subject: Re: [Rd] Recent and upcoming changes to R-devel
Sent: 07 July 2011 00:06
To: Duncan Murdoch
Cc: Prof Brian Ripley; R-devel at r-project.org
Subject: Re: [Rd] Recent and upcoming changes to R-devel
On Wed, Jul 6, 2011 at 9:42 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 11-07-06 9:25 AM, Kasper Daniel Hansen wrote: >> >> On Mon, Jul 4, 2011 at 8:08 AM, Prof Brian Ripley<ripley at stats.ox.ac.uk> >> wrote: >>> >>> In the near future all packages will have a name space. If the sources >>> do >>> not contain one, a default NAMESPACE file will be added. This again will >>> simplify the descriptions and also a lot of internal code. Maintainers >>> of >>> packages without name spaces (currently 42% of CRAN) are encouraged to >>> add >>> one themselves. >> >> This is great. However, it would also be great if a user could >> disable this for a given package at install time, for example with a >> command line argument to R CMD INSTALL. Use case: in the early stages >> of package development I find it incredible useful to not have a >> NAMESPACE. This is of course before I release it to anyone else; >> purely for development. >> >> My guess is that this has already been anticipated, but in case not, I >> wanted to raise the issue. > > I think the idea is to completely remove support for the bad search order > you get when you don't have a namespace. That search order is a mixed > blessing in debugging: it makes it easy to replace functions with new > versions, but it also makes it very easy to execute the wrong code if you > happen to have something sitting in the global environment that has a > conflicting name. > > It seems like something a front end could do to make assignInNamespace > easier to use to make working with namespaces easier. Indeed I find this change to be a very welcome addition to R that will make the life easier for many of us; especially when you are using someone else's package. My use case is also not debugging my own code when it is a at a semi-mature level. I am addressing the very early stages of developing a new package. In my workflow (which may differ from other people's; but I do think a substantial number would agree with me), the early stages of development usually entails bringing order to a number of R scripts; figuring out the structure of the basic objects as well as the arguments for the important functions/methods. In this early stage, almost any evaluation I do at the R prompt is followed by refactoring some part of the code (and then sourcing it into R). Once the code is semi-matured (after the first couple of weeks), I don't think I would mind a NAMESPACE at all, but I believe I would find it very frustrating during the very early development stage (which I am going through right now for one package and which I went through a month ago for another package). Kasper ______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel