Geoff Lee
2015-Mar-13 23:38 UTC
[Rd] Ah I've got it now .Thanks! RE: Understanding why "no metadata object found ... not exported?" warnings from the methods package exist, and what they mean
Ah, I've got it now.>From `?base:bindenv` comes> " The namespace environments of packages with namespaces are locked whenloaded." A locked environment> " prevents adding or removing variable bindings from the environment.Changing the value of a variable is still possible unless the binding has been locked" A bit of experimentation shows that as well as package namespace *environments* being locked, the *bindings* in the namespaces are locked. Locked bindings means that :> " The value of a locked binding cannot be changed".Since the superclass metadata object comes from another package, its binding (name) in that other package's namespace is locked and hence its value cannot be changed. So `mypkg` needs to work on a copy of the metadata object if it needs to update the value of the metadata object (which in fact it does need to do). An alternative to copying might be to temporarily unlock the binding in the namespace of the otherpackage, update the object, and relock the binding - but since I have only just learnt about locking environments and bindings, I have no idea what the consequences of that might be. I'll leave well enough alone. Many thanks for helping me learn about this. Geoff PS Apologies if I have sent too much to the list about this topic - if so let me know (gently please), so I can be better behaved in the future. -----Original Message----- From: Geoff Lee [mailto:geoff.lee99 at gmail.com] Sent: Saturday, 14 March 2015 9:30 AM To: 'John Chambers' Cc: 'r-devel at r-project.org' Subject: RE: [Rd] Understanding why "no metadata object found ... not exported?" warnings from the methods package exist, and what they mean Very many thanks indeed John for taking the time to look into this so closely and respond to me twice. I am hovering on the edge of understanding what was / is confusing me, and will read both your replies very closely. I think my conceptual problem relates to the difference between what happens to the *name* of an object (eg a function or a class (to be precise, a function object or a class metadata object)) and what happens to the *object* itself. Or in other terms, whether a namespace (possibly locked) needs to be updated, or the (state of the) object itself is what needs to be updated. I'll try and explain below. If `mypkg` want to use a function called `other_fun` from package `otherpkg` all I have to do is import the *name* of `other_fun` into the `mypkg` namespace. After that all the magic of making sure that the other_fun *object* works and can find everything it needs is taken care of for me. The other_fun object knows the enclosing environment where it was created and finds any information it needs about additional functions etc, that may or may not have been exported by package otherpkg behind the scenes. My reasoning was that the same should apply to the *names* of classes as well. If `mypkg` wanted to use a class called `OtherClass` from package `otherpkg` all it would need to do was import the *name* of `OtherClass` into the `mypkg` namespace. After that the `OtherClass` (metadata) object would know where it came from and look after itself. In particular, if the operation of the OtherClass (metadata) object involved any superclasses (or later on, subclasses), the manipulations required would occur at the object level, not at the *name* level. I can see why it is necessary to update the metadata object itself, because functions like `setIs` and `setClassUnion` allow the upstream parentage of a class to be altered post hoc in ways which depend upon what else is loaded, and a class must be able to find that type of information if inheritance is going to work. But at the moment it seems that it is necessary to import the *name* of the superclass(es) into the `mypkg` namespace as well, and that is what I can't fully follow. I do confess that I get quite lost when I try and follow my logic chain through to the implementation level for class metadata objects. I have got as far as understanding that the *name* of a metadata object is mangled and hidden (I think the real *name* of `OtherClass` is usually `.__C__OtherClass` ). And that the metadata objects themselves need to be able to maintain and manage any superclass and subclass relationships as they evolve. But when I get to trying to figure out how on earth the various metadata objects would avoid the garbage collector, and cope with unevaluated expressions, promises, pass by copying etc I am (well) over the boundaries of my understanding. Thinking as I type, if the current warning message is telling me that I am getting a copy of the superclass metadata object, rather than a copied name which points to the original metadata object itself, I can begin to see why that would be a worry. Mmmm, more for me to think about. Once again, many many thanks for helping me work my way towards understanding this Geoff -----Original Message----- From: John Chambers [mailto:jmc at r-project.org] Sent: Saturday, 14 March 2015 8:11 AM To: Geoff Lee Cc: r-devel at r-project.org Subject: Re: [Rd] Understanding why "no metadata object found ... not exported?" warnings from the methods package exist, and what they mean On looking more closely, the purpose of finding the class definition is to update the entry for the new relationship, as the warning message suggests. That requires that the namespace holding the definition be writable. In the case of subclass information, the original namespace is very likely to be locked, if it's not the package currently being loaded. Copying the definition in order to update subclass information seems the only reasonable choice, and no warning message is needed. A revised version will omit this message. On Mar 13, 2015, at 9:32 AM, John Chambers <jmc at r-project.org> wrote:> This warning message is on my to-look-at list; I agree that sometimes it'sobviously possible for the system to get the information if it tries hard enough.> > The message means what it says: Class information in a session includesthe currently loaded subclasses of a particular class. Not critical but sometimes useful.> > In this case, (as I understand it without having looked recently), theissue 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 classobject? 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 >> github.com/Geoff99/Examples/tree/SpatialLinesNULL >> >> >> >> I have asked a (far too) long question on Stack Overflow (see >> stackoverflow.com/questions/28871632/how-to-resolve-warning-me >> ssages- >> 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 >> >> >> >> stackoverflow.com/questions/28871632/how-to-resolve-warning-me >> ssages- >> 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 >> stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel at r-project.org mailing list > stat.ethz.ch/mailman/listinfo/r-devel
Reasonably Related Threads
- Understanding why "no metadata object found ... not exported?" warnings from the methods package exist, and what they mean
- Understanding why "no metadata object found ... not exported?" warnings from the methods package exist, and what they mean
- Understanding why "no metadata object found ... not exported?" warnings from the methods package exist, and what they mean
- Upgrading a package to which other packages are LinkingTo
- Installing rgeos on Mac OS X 10.4 (was Re: "package 'stringr' does not have a name space"