From luke at stat.uiowa.edu  Mon Oct  9 17:33:12 2006
From: luke at stat.uiowa.edu (Luke Tierney)
Date: Mon, 9 Oct 2006 10:33:12 -0500 (CDT)
Subject: [Rd] operator :: and symbols not in the namespace of a package
 with a namespace
In-Reply-To: <Pine.LNX.4.64.0610091611110.17674@gannet.stats.ox.ac.uk>
References: <20061006130505.A50374BEC2@slim.kubism.ku.dk>
	<45265A8A.6060505@stats.uwo.ca>
	<Pine.LNX.4.64.0610060938000.7912@nokomis.stat.uiowa.edu>
	<Pine.LNX.4.64.0610091611110.17674@gannet.stats.ox.ac.uk>
Message-ID: <Pine.LNX.4.64.0610091032220.18405@nokomis.stat.uiowa.edu>

On Mon, 9 Oct 2006, Prof Brian Ripley wrote:

> 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().

This behavior does not seem desireable. Can you give specific
examples?

Best,

luke

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu




[Rd] operator :: and symbols not in the namespace of a package with a namespace
Luke Tierney