[Rd] Package "datasets" not exporting anything on a recent R-2.15.1-patched

Laurent Gautier lgautier at gmail.com
Mon Aug 27 14:45:02 CEST 2012


On 2012-08-27 11:32, Uwe Ligges wrote:
>
>
> On 26.08.2012 20:01, Laurent Gautier wrote:
>> On 2012-08-26 19:27, Prof Brian Ripley wrote:
>>> On 26/08/2012 18:20, Laurent Gautier wrote:
>>>> On 2012-08-26 19:03, Prof Brian Ripley wrote:
>>>>> On 26/08/2012 17:25, Laurent Gautier wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I just stumbled on the following apparent oddity: the package
>>>>>> "datasets"
>>>>>> does not appear to export anything out of its namespace:
>>>>>>
>>>>>>  > ns_datasets <- getNamespace('datasets')
>>>>>>  > getNamespaceExports(ns_datasets)
>>>>>> character(0)
>>>>>>
>>>>>> Not the case with other packages (example here with "utils"):
>>>>>>  > ns_utils <- getNamespace('utils')
>>>>>>  > head(getNamespaceExports(ns_utils))
>>>>>> [1] "?"            ".DollarNames" "adist"        "alarm" "apropos"
>>>>>> [6] "aregexec"
>>>>>>
>>>>>> Is this a temporary glitch, or is there something new and 
>>>>>> specific to
>>>>>> "datasets" ?
>>>>>
>>>>> Not new, been so since R 2.14.0.
>>>>>
>>>>> The package contains no R code: the only reason it has a namespace is
>>>>> that since 2.14.0 all packages must have one.
>>>>>
>>>>> There are other data-only packages, but not in base R.
>>>>>
>>>>> Lazy-loaded data has not been part of the namespace for a long time:
>>>>> they are directly in the package's environment.  The reason is the
>>>>> namespace scoping rules: if the package's datasets were in its
>>>>> namespace, they would be found before any other dataset of that name
>>>>> by the package's R functions.
>>>>>
>>>> Thanks for the quick answer and explanations. The last paragraph above
>>>> is leaving me with the wish to understand more before I comment on it.
>>>> Would you have an example of finding a dataset in a package's 
>>>> namespace
>>>> (before a dataset with the same name in an other package further 
>>>> down in
>>>> the search path) being a problem ?
>>>
>>> It does not happen now, but for example MASS contains both datasets
>>> and analysis functions and when the datasets were in the namespace you
>>> got them before other datasets (e.g. modified versions) of the same 
>>> name.
>>
>> I am seeing two ways for datasets to be used:
>> A- as internal data for necessary to a function in a package (e.g,
>> conversion tables). Not very frequent, from my limited experience.
>> B- as example data, used in the documentation. The most frequent usage.
>>
>> For A/, the user is not expected to modify the data.
>
> In that case, you can provide the data as an object defined within the 
> /R directory, for example.

Exactly. This is making us agree that datasets are indeed just objects 
in a package.

>
>
>> For B/, the data are typically passed to functions (to use an example
>> from MASS, "huber(chem)").
>
> In that case, you do not want to have it in your NAMESPACE, since you 
> just pass those data in a function call.


Yet having it in a namespace would not cause any harm, wouldn't it ?

Having it in a namespace would also have the added benefits:
- loading up a dataset will not overwrite silently any existing dataset 
currently in .GlobalEnv
- should an identical name for a dataset be found in several packages, 
one could refer to it with the "::" operator. I am aware of the argument 
"package" to the function "data()", but regret the apparent lack of 
general rule.
- should one wish to list the objects defined (and eventually exported) 
by a package the use of one function would be sufficient.

May be I am missing a fundamental point, but if my memory is correct the 
package "datasets" used to list its data objects when 
getNamespaceExports() was called.

>
> Uwe Ligges
>
>
>
>> I thought a bit about it, but still do no see where exactly this would
>> be a problem.
>>
>> An other example available in R is the vector "letters" (in base). It
>> can be thought of as a dataset, yet it is
>> - in a namespace
>>
>>  > "letters" %in% getNamespaceExports(getNamespace("base"))
>> [1] TRUE
>>
>> - probably used in the two situations A/ and B/ above.
>>
>>
>>
>>
>>
>>
>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>> Laurent
>>>
>>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list