For the details, please consult the respective methods' manual pages.
psms(object, ...)
peaks(object, ...)
modifications(object, ...)
database(object, ...)
rtime(object, ...)
tic(object, ...)
spectra(object, ...)
intensity(object, ...)
mz(object, ...)
peptides(object, ...)
proteins(object, ...)
accessions(object, ...)
scans(object, ...)
mass(object, ...)
ions(object, ...)
chromatograms(object, ...)
chromatogram(object, ...)When should one define a generics?
Generics are appropriate for functions that have generic
names, i.e. names that occur in multiple circumstances, (with
different input classes, most often defined in different packages)
or, when (multiple) dispatching is better handled by the generics
mechanism rather than the developer. The dispatching mechanism will
then automatically call the appropriate method and save the user
from explicitly calling package::method or the developer to
handle the multiple input types cases. When no such conflict exists
or is unlikely to happen (for example when the name of the function
is specific to a package or domain, or for class slots accessors and
replacement methods), the usage of a generic is arguably
questionable, and in most of these cases, simple, straightforward
functions would be perfectly valid.
When to define a generic in ProtGenerics?
ProtGenerics is not meant to be the central package for
generics, nor should it stop developers from defining the generics
they need. It is a means to centralise generics that are defined in
different packages (for example mzR::psms and
mzID::psms, or IRanges::score and mzR::score,
now BioGenerics::score) or generics that live in a rather big
package (say mzR) on which one wouldn't want to depend just
for the sake of that generics' definition.
The goal of ProtGenerics is to step in when namespace
conflicts arise so as to to facilitate inter-operability of
packages. In case such conflict appears due to multiple generics, we
would (1) add these same definitions in ProtGenerics, (2)
remove the definitions from the packages they stem from, which then
(3) only need to import ProtGenerics. This would be very
minor/straightforward changes for the developers and would resolve
issues when they arise.
More generics can be added on request by opening an issue or sending a pull request on: https://github.com/lgatto/ProtGenerics
showMethods for displaying a summary of the
methods defined for a given generic function.
selectMethod for getting the definition of
a specific method.
setGeneric and
setMethod for defining generics and methods.
## List all the symbols defined in this package:
ls('package:ProtGenerics')
## Not run:
# ## What methods exists for 'peaks'
# showMethods("peaks")
#
# ## To look at one method in particular
# getMethod("peaks", "mzRpwiz")
# ## End(Not run)
Run the code above in your browser using DataLab