From ripley at stats.ox.ac.uk  Mon Oct  9 17:18:13 2006
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Mon, 9 Oct 2006 16:18:13 +0100 (BST)
Subject: [Rd] operator :: and symbols not in the namespace of a package
 with a namespace
In-Reply-To: <Pine.LNX.4.64.0610060938000.7912@nokomis.stat.uiowa.edu>
References: <20061006130505.A50374BEC2@slim.kubism.ku.dk>
	<45265A8A.6060505@stats.uwo.ca>
	<Pine.LNX.4.64.0610060938000.7912@nokomis.stat.uiowa.edu>
Message-ID: <Pine.LNX.4.64.0610091611110.17674@gannet.stats.ox.ac.uk>

On Fri, 6 Oct 2006, Luke Tierney wrote:

> On Fri, 6 Oct 2006, Duncan Murdoch wrote:
>
>> On 10/6/2006 9:05 AM, thomas.friedrichsmeier at rub.de wrote:
>>> Full_Name: Thomas Friedrichsmeier
>>> Version: 2.4.0
>>> OS: GNU/Linux
>>> Submission from: (NULL) (84.61.116.51)
>>>
>>>
>>> Since R 2.4.0, operator "::" also returns objects in the package environment, if
>>> the package does not have a namespace. This is a very welcome addition.
>>>
>>> Additional wish:
>>> If a package has a namespace, but does not place all symbols in that namespace,
>>> lookup will still fail. For example in package boot (version 1.2-26):
>>>
>>> library (boot)
>>> exists ("motor", envir=as.environment ("package:boot"))   # TRUE
>>> getAnywhere ("motor")                                     # found in
>>> package:boot
>>> boot::motor                                               # error not in
>>> namespace
>>>
>>> This is as documented, but I think it would be convenient, if boot::motor would
>>> also return the object in this case.
>>
>> At first I was ready to disagree with you, telling you to use the ":::"
>> operator for something that is not exported:  but in fact motor is a
>> dataset, so it is exported from the package by being loaded into the
>> package environment when the package is loaded.  I agree that the "::"
>> operator should find it.
>
> It might be a good idea to rethink the decision to have data be
> handled specially instead of having data sets be treated as ordinary
> exported variables.  There may be a good reason for doing what we do
> now but I don't know what it is.  If there really is a good reason to
> continue this then maybe we should think about this addition.  It
> doesn't feel like the right thing to do but may be harmless.

The reason was (and is) that if datasets are in the namespace, functions 
in the namespace find them ahead of a dataset of the same name in the 
user's workspace.  (This broke the MASS scripts, for example, and also 
affects car.)  (We do have a mechanism to put system datasets in the 
namespace where this is the desired behaviour, but it seems uncommon.)  I 
really don't fancy explaining to our beginning students that when they are 
asked to correct some entries in a dataset some functions will see the 
corrected version and some the original if they just use fix().

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595




[Rd] operator :: and symbols not in the namespace of a package with a namespace
Prof Brian Ripley