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-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf 
Of Kasper Daniel Hansen [kasperdanielhan...@gmail.com]
Sent: 07 July 2011 00:06
To: Duncan Murdoch
Cc: Prof Brian Ripley; R-devel@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.dun...@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<rip...@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to