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

From: Pfaff, Bernhard Dr. <>
Date: Fri 03 Nov 2006 - 15:55:28 GMT

Dear John, Dear Seth,

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

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


>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 <> 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
>> ______________________________________________
>> mailing list
> [[alternative HTML version deleted]]
> mailing list

Confidentiality Note: The information contained in this mess...{{dropped}} mailing list Received on Sat Nov 04 11:13:42 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Sat 04 Nov 2006 - 18:30:34 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.