[Rd] function remains loaded in the search space after detaching the package

Prof Brian Ripley ripley at stats.ox.ac.uk
Fri Feb 24 15:01:10 CET 2012


On Fri, 24 Feb 2012, Joris Meys wrote:

> Indeed, when trying :
>
>> detach('package:gdata',unload=TRUE)
>> print(object.size(iris),units='Kb')
> [1] 6424
>
> However, when I do :
>> unloadNamespace('gdata')
>> gc()
>         used (Mb) gc trigger (Mb) max used (Mb)
> Ncells 380471 10.2     667722 17.9   597831 16.0
> Vcells 353363  2.7     905753  7.0   902804  6.9
>
> The function used is still print.object_size from gdata
>
>> print(object.size(iris),units='Kb')
> [1] 6424
>
> But it can't be found any more...
>
>> getAnywhere('print.object_size')
> A single object matching ‘print.object_size’ was found
> It was found in the following places
>  registered S3 method for print from namespace utils
>  namespace:utils
> with value
> ... (here is indeed the code of the original print.object_size)

As

getS3method('print', 'object_size')

would have confirmed the expectations of a 'one' with a less sketchy
understanding of R.

> This is not some kind of behaviour one would expect. I have no clue
> how to solve this, but I believe it's safe to say that there's room
> for improvement somewhere to avoid calling a function that's
> apparently not in the search space. Any other ideas?

R relies very heavily on 'calling a function that's apparently not in 
the search space': that's much of the point of namespaces.

Professor Ripley

> Cheers
> Joris
>
> On Fri, Feb 24, 2012 at 1:08 PM, Prof Brian Ripley
> <ripley at stats.ox.ac.uk> wrote:
>> On 24/02/2012 11:20, Martin Maechler wrote:
>>>>>>>>
>>>>>>>> Joris Meys<jorismeys at gmail.com>
>>>>>>>>     on Fri, 24 Feb 2012 11:24:35 +0100 writes:
>>>
>>>
>>>     >  I ran into some very irritating behaviour I don't
>>>     >  understand.  Let me illustrate with the package gdata()
>>>     >  and the function print.object_size() :
>>>
>>>     >>  print(object.size(iris),units='Kb')
>>>     >  6.3 Kb
>>>     >>  getAnywhere(print.object_size)
>>>     >  A single object matching ‘print.object_size’ was found It
>>>     >  was found in the following places registered S3 method for
>>>     >  print from namespace utils namespace:utils with value ...
>>>
>>>     >  All is well. So now I load gdata
>>>
>>>     >>  require(gdata)
>>>     >  Loading required package: gdata ...  The following
>>>     >  object(s) are masked from ‘package:utils’:
>>>
>>>     >      object.size
>>>
>>>     >  OK, this is what I would expect:
>>>
>>>     >>  print(object.size(iris),units='Kb')
>>>     >  [1] 6424
>>>     >>  getAnywhere(print.object_size)
>>>     >  2 differing objects matching ‘print.object_size’ were
>>>     >  found in the following places registered S3 method for
>>>     >  print from namespace utils namespace:gdata namespace:utils
>>>     >  Use [] to view one of them
>>>
>>>     >  Now I detach gdata again
>>>
>>>     >>  detach(package:gdata)
>>>
>>>     >  But the function print.object_size is still the default
>>>     >  for object_size objects!
>>>
>>>     >>  print(object.size(iris),units='Kb')
>>>     >  [1] 6424
>>>
>>>     >  And it can still be found as well:
>>>
>>>     >>  getAnywhere(print.object_size)
>>>     >  2 differing objects matching ‘print.object_size’ were
>>>     >  found in the following places registered S3 method for
>>>     >  print from namespace utils namespace:gdata namespace:utils
>>>     >  Use [] to view one of them
>>>
>>>     >  Am I missing something?
>>>
>>> Yes:  the argument  'unload'   of detach().
>>>
>>> In general: Now that every package has a namespace,
>>> you (and others) should learn the difference between
>>> attaching and loading - and hence  detach()ing and unloading
>>> a package with its namespace.
>>>
>>>  ?detach
>>>  ?library
>>>
>>> etc should give a good start.
>>
>>
>> A very good point, but actually there is more to this one.  'gdata'
>> registers an S3 method which overwrites the one from utils.  Unloading a
>> namespace does not unregister its methods (and registration has no stack, so
>> there is no way R knows what was there before).
>>
>> --
>> 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
>
>
>
> -- 
> Joris Meys
> Statistical consultant
>
> Ghent University
> Faculty of Bioscience Engineering
> Department of Mathematical Modelling, Statistics and Bio-Informatics
>
> tel : +32 9 264 59 87
> Joris.Meys at Ugent.be
> -------------------------------
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
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


More information about the R-devel mailing list