Skip to content

Suggestion: Not having to export .conflicts.OK in name spaces

5 messages · Seth Falcon, Martin Maechler, Henrik Bengtsson

Original
Henrik Bengtsson
# 
Currently library() and attach() fail to locate an existing
'.conflicts.OK' in a package wit name space, unless it is exported.
Since there should be little interest in exporting '.conflicts.OK'
otherwise, one may argue that those methods should look for
'.conflicts.OK' even if it is not exported.  If so, a patch for
library() is:
Index: library.R
===================================================================
--- library.R   (revision 51296)
+++ library.R   (working copy)
@@ -312,7 +312,7 @@
                     nogenerics <-
                         !.isMethodsDispatchOn() || checkNoGenerics(env, package
)
                     if(warn.conflicts &&
-                       !exists(".conflicts.OK", envir = env, inherits = FALSE))

+                       !exists(".conflicts.OK", envir = ns, inherits = FALSE))
                         checkConflicts(package, pkgname, pkgpath,
                                        nogenerics, ns)
                     runUserHook(package, pkgpath)


In order to be consistent, a patch for attach() should also be
provided, which requires some more changes, but I won't spend time on
that unless the above is a wanted feature.

/Henrik
2 days later
Seth Falcon
#
On 3/17/10 9:11 AM, Henrik Bengtsson wrote:
I guess I agree that there is no real value in forcing .conflicts.OK to 
be exported.  OTOH, this seems like a dubious feature to begin.  When is 
it a good idea to use it?

+ seth
2 days later
Martin Maechler
# 

        
SF> On 3/17/10 9:11 AM, Henrik Bengtsson wrote:

        
>> Currently library() and attach() fail to locate an
    >> existing '.conflicts.OK' in a package wit name space,
    >> unless it is exported.  Since there should be little
    >> interest in exporting '.conflicts.OK' otherwise, one may
    >> argue that those methods should look for '.conflicts.OK'
    >> even if it is not exported.

    SF> I guess I agree that there is no real value in forcing
    SF> .conflicts.OK to be exported.  
so do I.

    SF> OTOH, this seems like a dubious feature to begin.  When
    SF> is it a good idea to use it?

in cases, the package author thinks (s)he knows what (s)he is
doing;
e.g. in the case of Matrix, I could argue that I know about the
current conflicts, and I would *not* want the users of my
package be intimidated by warnings about maskings...

Martin

    SF> + seth

    SF> -- Seth Falcon | @sfalcon | http://userprimary.net/

    SF> ______________________________________________
    SF> R-devel at r-project.org mailing list
    SF> https://stat.ethz.ch/mailman/listinfo/r-devel

  
  


  


      

    

    

      
      

        


  

        

      Seth Falcon
    

    

      
      #
    

  


  

      
On 3/22/10 3:57 AM, Martin Maechler wrote:

            

      
      
      
    

        
So I guess we agree that Henrik's patch would be worth applying.

@Henrik: if you resend your patch with the additions for attach, I will 
see about putting it in.

            

      
      
      
    

        
I can't say that this convinces me that .conflicts.OK is OK.  Are there 
package authors who realize they do not know what they are doing enough 
to keep the warning messages :-P

+ seth

  
    

      
      
    

  


  


      

    

    
4 days later

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

      
Hi.

        
On Mon, Mar 22, 2010 at 5:36 PM, Seth Falcon <seth at userprimary.net> wrote:

            

      
      
      
    

        
When looking more carefully at base::attach(), I see that there is
nothing to do, because attach() takes a data.frame, a list, an
environment, NULL, or a file saved using base::save().  None of these
can have a name space.

The scenario I was "worrying about" was when you attach() the
environment of a package with a namespace, e.g.

envir <- as.environment("package:graphics");
envir2 <- attach(envir, name="foo");
ls(envir=envir2, all.names=TRUE);

but to the best of my understanding it is only exported objects that
are attached, i.e. if .conflicts.OK is not exported by the package,
then it won't be attached and hence not exist either way.  Is that
correct?

envir <- as.environment("package:R.utils");
envir2 <- attach(envir, name="foo");
ls(envir=envir2, all.names=TRUE);

            

      
      
      
    

        
I define throw.default() in R.methodsS3:

            

      
      
      
    

        
function (...)
{
    stop(...)
}
<environment: namespace:R.methodsS3>

In R.oo, which loads R.methodsS3, I override this with:

            

      
      
      
    

        
function (...)
{
    throw(Exception(...))
}
<environment: namespace:R.oo>

The Exception class is defined in R.oo.  If someone loads R.methodsS3
alone, you get a throw() method.  Someone loading R.oo will get the a
throw() that is backward compatible but with some extra bells and
whistles recording the strack trace etc.  This is an intended design.

So when I load R.oo, I don't want the warning of overloading throw()
in R.methodsS3.  Is there an alternative for me?

Ideally, there should be a way to specify which objects are "ok",
instead of all or none.

Thanks

Henrik