The "undocumented methods" part of this one is easily fixed: undoc() was
calling getMethods() to get the methods defined. But this gets _all_
the visible methods of the generic, hence everyone was being charged for
everyone else's methods. Instead, undoc() should call the function
getMethodsMetaData(); it gets, as its name suggests, only the metadata
describing the methods assigned in this environment.
(The documentation for getMethods() describes itself correctly, but I'll
add a note pointing to getMethodsMetaData.)
The extra function warnings are a little subtler to suppress. The right
approach seems to be to ignore generic functions that "correspond to" a
nongeneric in another package. The subtlety is defining "correspond
to": intuitively, the generic should have been derived from the
nongeneric by a setGeneric() call, direct or implicit. We can check
this by comparing the default method to the nongeneric function.
Meanwhile, I will commit the fix for undocumented methods after running
the checks.
John
Roger Koenker wrote:
>
> I have another S4 methods query -- this time about undocumented objects:
> I'm now getting the following warning from R CMD check SparseM:
>
> * checking for missing documentation entries ... WARNING
> Undocumented code objects:
> %x% as.matrix diag diag<- diff t
> Undocumented S4 methods:
> \S4method{coerce}{ANY,array} \S4method{coerce}{ANY,call}
> \S4method{coerce}{ANY,character} \S4method{coerce}{ANY,complex}
> \S4method{coerce}{ANY,environment} \S4method{coerce}{ANY,expression}
> \S4method{coerce}{ANY,function} \S4method{coerce}{ANY,integer}
> \S4method{coerce}{ANY,list} \S4method{coerce}{ANY,logical}
> \S4method{coerce}{ANY,matrix} \S4method{coerce}{ANY,name}
> \S4method{coerce}{ANY,numeric} \S4method{coerce}{ANY,single}
> \S4method{coerce}{ANY,ts} \S4method{coerce}{ANY,vector}
> \S4method{coerce}{ANY,NULL}
> \S4method{coerce}{vector,matrix.diag.csr}
> \S4method{diff}{matrix.csr} \S4method{initialize}{traceable}
> \S4method{initialize}{signature} \S4method{initialize}{environment}
>
> A couple of these are directly related to the package, but the rest
> seem to be items that I wouldn't have thought that I should be responsible
> for documenting. I'm wondering whether the coerce items are related to
> my earlier query. Even supposing that they were due to some blunder
> of mine, I'm still puzzled by the initialize items which were present
> even before I began to mess with my new setClass strategy. Again,
> many thanks for any suggestions.
>
> url: www.econ.uiuc.edu/~roger/my.html Roger Koenker
> email [EMAIL PROTECTED] Department of Economics
> vox: 217-333-4558 University of Illinois
> fax: 217-244-6678 Champaign, IL 61820
>
> ______________________________________________
> [EMAIL PROTECTED] mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
--
John M. Chambers [EMAIL PROTECTED]
Bell Labs, Lucent Technologies office: (908)582-2681
700 Mountain Avenue, Room 2C-282 fax: (908)582-3340
Murray Hill, NJ 07974 web: http://www.cs.bell-labs.com/~jmc
______________________________________________
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
