[Rd] Formal methods are not loaded from NAMESPACE in reloadedworkspace image

Pfaff, Bernhard Dr. Bernhard_Pfaff at fra.invesco.com
Fri Nov 3 16:55:28 CET 2006

Dear John, Dear Seth,

many (a thousands) thanks for your clarification and highlighting of the

>It's not a simple serialization issue, but related to the initial 
>computations when a saved image is reloaded at the start of a session, 
>so the implication is less general than you imply.

Hm, yes, that seems to be true. I do not know what the R-wizard Prof.
Douglas Bates has done, but going through the same exercise with:


saving the work space (without moving it to another file), quitting R
and starting such that the previously work space is restored, will yield
the following:

> ls()
[1] "fm1" "fm2"
> showMethods("summary")

Function "summary":
 <not a generic function>

> fm1
Loading required package: lme4
Loading required package: Matrix
Loading required package: lattice

## output as expected, but omitted here

Well, John, referring to your question. IMHO it is a question how useRs
work with R. Personnaly, I almost never work with work spaces but rather
scripts: write it - like it or fudge it. Anyway, a useR has pointed me
to this behaviour and I reckon that he uses the 'save work
space'-approach for an E-lab class that he teaches.   

Aside, of this issue and something more for R-Core, I am wondering if
some hint/pointer should be placed in the R-ext document (maybe in the
section 'Package name spaces' and/or in the subsection 'The DESCRIPTION
file'). I have re-read it, but could not find a hint with respect to
'methods' and 'S4'.

Let me thank you once more for your time taken, patience devoted and
enlightenment given to this problem. I must confess, that 'serialization
of R objects' is beyond the scope of my computer literacy as an



>If you move the saved image to another file, say "savedImage", then:
> > load("savedImage")
> > library(urca)
> > showMethods("summary")
>Function: summary (package base)
>and summary(lc.df) then works as expected.
>So the workaround, other than inserting all the import(methods), etc. 
>you can think of, seems to be to save/load explicitly.
>Seth Falcon wrote:
>> John Chambers <jmc at r-project.org> writes:
>>> I haven't had a chance to verify these exact examples, but 
>the likely 
>>> explanation is that loading the workspace does not cache the  saved 
>>> methods.  Assuming this is indeed what's happening, the 
>workaround is to 
>>> cache them "manually" by the call:
>>>   cacheMetaData(.GlobalEnv)
>>> (after attaching the relevant library)
>>> It would be nice to have the same effect occur 
>automatically, but there 
>>> may be issues since the needed class definitions may not be 
>>> when the saved workspace is reloaded.
>>> A natural question to ask is whether there is some 
>practical motivation 
>>> for this exercise.
>> The main use case is that since serialization of objects is such an
>> R-ish thing to do, you really want to have deserialized S4 instances
>> "work" properly when loaded.
>> I admit that it is also useful to be able to load an arbitrary object
>> and inspect it even if it will be "broken" (without this, it would be
>> very hard to write any sort of automated class update code). 
> It would
>> seem that this behavior could be achieved in a force=TRUE mode and
>> that otherwise, it would be an error to deserialize an S4 instance
>> when the class def is not available.
>> + seth
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>	[[alternative HTML version deleted]]
>R-devel at r-project.org mailing list
Confidentiality Note: The information contained in this mess...{{dropped}}

More information about the R-devel mailing list