Skip to content

Methods package: One of those strategy questions

4 messages · Thomas Lumley, John Chambers, Brian Ripley

Original
John Chambers
# 
I had better mention this one separately, since until it's settled you 
need a workaround.

If you define methods for primitives now, this does NOT create an
explicit generic function for, say, "[", so that the original primitive
computations still run.

This means that the method dispatch has to be turned on for that
function somehow else.

The proposal is that the library() and attach() functions would do a
check for methods metadata and turn on methods search for the functions
found.  (Recent changes to the metadata make this a reasonably efficient
operation.)

Until this is implemented, you will need to force the same computation
from the .First.lib function in your package (ONLY needed if you have
methods for primitives).

The code needed is something like this (inside .First.lib, which gets a
second argument "pkgname":

    where <- match(paste("package:", pkgname, sep=""), search())
    cacheMetaData(as.environment(where))

(Extra calls to cacheMetaData shouldn't hurt, beyond a moderate bit of
extra computation, so this should not be a disaster even after
modifications to library()).

John
Thomas Lumley
#
On Tue, 13 Nov 2001, John Chambers wrote:

            

      
      
      
    

        
Is this true whenever you define a method for a primitive or only if
that primitive hasn't already got methods defined for it?

	-thomas

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

  
  


  


      

    

    

      
      

        


  

        

      John Chambers
    

    

      
      #
    

  


  

      
Thomas Lumley wrote:

            

      
      
      
    

        
The former, unfortunately.  As the function's name suggests,
cacheMetaData collects and merges information about all the currently
visible methods.  One doesn't want to do this merge on each dispatch, so
it's triggered by any change in the visible  methods (e.g., a call to
setMethod or a change in the search list).  So "turned on"  really
should have been "notified of a change in the methods".

If I don't hear objections, I plan to add checkMetaData to library,
attach, and detach fairly soon, which should cover the problem.

John

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Tue, 13 Nov 2001, John Chambers wrote:

        

            

      
      
      
    

        
You will do some rough performance tests?  We (including I) have forgotten
to do so a few too many times ....

Brian