[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

Geoff Lee geoff.lee99 at gmail.com
Sat Mar 14 00:38:08 CET 2015 

Ah, I've got it now.

>From `?base:bindenv` comes

> " The namespace environments of packages with namespaces are locked when
loaded."

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'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-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
>> 
>> 
>> 
>> http://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
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list