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

From: Prof Brian Ripley <ripley_at_stats.ox.ac.uk>
Date: Fri, 24 Feb 2012 14:01:10 +0000 (GMT)

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

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

Received on Fri 24 Feb 2012 - 14:11:23 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 24 Feb 2012 - 15:50:20 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive