[Rd] Understanding why "no metadata object found ... not exported?" warnings from the methods package exist, and what they mean

[John Chambers]

This warning message is on my to-look-at list; I agree that sometimes it's obviously possible for the system to get the information if it tries hard enough.

The message means what it says:  Class information in a session includes the currently loaded subclasses of a particular class.  Not critical but sometimes useful.

In this case, (as I understand it without having looked recently), the issue is that the "rgeos" namespace has not been loaded, although a subclass of a class in that package has.  

So, should that namespace be loaded, to access (presumably) the class object?  Or the copy made silently somewhere?  It's probably true that the warning is not being seen by the owner of the package that could fix the problem.

John



On Mar 12, 2015, at 1:47 PM, Geoff Lee <geoff.lee99 at gmail.com> wrote:

> Hi
> 
> 
> 
> I am seeking to understand why the methods package (to be specific
> `methods:::.findOrCopyClass` when called by `setIs` when called by
> `setClass`) emits a warning message such as
> 
> 
> 
> ` class "SpatialLinesNULL" is defined (with package slot 'rgeos') but no
> metadata object found to revise subclass information---not exported?  Making
> a copy in package 'minweSpatialNULL `
> 
> 
> 
> when I try to `R cmd build .` and then R cmd check *.gz` (or alternatively
> `devtools::load_all()`) the package I am building.
> 
> 
> 
> What I don't really follow is why I am being warned when evidently the
> methods package *can* actually find the metadata object in order to make a
> copy of it (or does it just copy a name which binds to the original metadata
> object - I'm not clear on that).  What is the danger I am being warned
> about, and what, ideally should I do about it?  
> 
> 
> 
> In practice I know I can make the message go away by using
> `importClassesFrom(rgeos,SpatialLinesNULL)` in my NAMESPACE file now that
> Edzer Pebesma has arranged for a version of rgeos which exports
> SpatialLinesNULL.  
> 
> 
> 
> But why do I need to explicitly import the superclass of the class I am
> actually using?  If I were using a *function* from rgeos, which in turn
> utilised a second non-exported function from rgeos, the package namespace
> environments mechanism would take care of how to find and access that second
> function, silently.  It wouldn't warn me about it and make me import it - in
> fact avoiding that is as I understand it a major purpose of the packaging
> namespace process.
> 
> 
> 
> There is obviously something I am missing, but having thought and read for
> several days I am at a loss as to what.
> 
> 
> 
> Thanks heaps in advance for any illumination that you can offer me!
> 
> 
> 
> What I have done already.
> 
> 
> 
> I have a toy example in folder SpatialLinesNULL of branch SpatialLinesNULL
> in a github repo at http://github.com/Geoff99/Examples/tree/SpatialLinesNULL
> 
> 
> 
> I have asked a (far too) long question on Stack Overflow (see
> http://stackoverflow.com/questions/28871632/how-to-resolve-warning-messages-
> metadata-object-not-found-spatiallinesnull-cla/29010169#29010169), the
> specific aspect of which was very kindly and quickly answered by Edzer
> Pebesma.
> 
> 
> 
> I have read the methods documentation ( which was very valuable indeed) and
> have posted my understanding of what I learnt from that (and from stepping
> through my toy example in the debugger) as a (once again quite long) answer
> on Stack Overflow here
> 
> 
> 
> http://stackoverflow.com/questions/28871632/how-to-resolve-warning-messages-
> metadata-object-not-found-spatiallinesnull-cla/29010169#29010169
> 
> 
> 
> PS If I should be asking this somewhere else, please just say.
> 
> 
> 
> PPS The primary purpose of the package I am building (not the toy example)
> is to help me learn about programming and packaging in R, hence my desire to
> chase down and understand this warning fully.
> 
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel