Hopefully it could be implemented with minimal bloat, but I get your
point. The intent is to clarify the source of the class, since it
would not otherwise be imported. I think this is a fairly common case
that is worth solving if it doesn't add too much complexity.
On Wed, Jan 30, 2019 at 2:31 PM Pages, Herve <hpa...@fredhutch.org> wrote:
>
> Hi Michael,
>
> So IIUC this upfront class registration wouldn't do much beside making
> the "no definition for class 'seurat'" message issued by setMethod
> disappear. Maybe that's not enough to justify adding more bloat to the
> methods package?
>
> My 2 cents,
>
> H.
>
>
> On 1/30/19 13:35, Michael Lawrence via Bioc-devel wrote:
> > Unrelated to the specific question, a generic function introduces more
> > vocabulary into the ecosystem. Since SingleCellExperiment defines the
> > standard interface, why not make a new method on logcounts()?
> >
> > Back on topic, what if the methods package were to support forward
> > class declarations? For example,
> >
> > setExternalClass("seurat", package="seurat")
> >
> > I have no idea how to implement that, but perhaps we could at least
> > agree on the API. Honestly, it may be that just some dummy class would
> > work for method registration. But it's nice to be explicit and to list
> > the source package, even if nothing is formally checked.
> >
> > Michael
> >
> >
> >
> > On Wed, Jan 30, 2019 at 12:41 PM Brendan Innes
> > <brendan.in...@mail.utoronto.ca> wrote:
> >> Thanks Martin!
> >>
> >>
> >> The fun strategy (zzz.R .onLoad setHook trick) worked well, except for
> >> setting this particular method:
> >>
> >>
> >> setMethod(scClustViz::getDR,"SingleCellExperiment",function(x,DRtype)
> >> {
> >> if
> >> (any(grepl(DRtype,SingleCellExperiment::reducedDimNames(x),ignore.case=T)))
> >> {
> >> SingleCellExperiment::reducedDim(x,grep(DRtype,
> >>
> >> SingleCellExperiment::reducedDimNames(x),
> >> ignore.case=T,value=T))
> >> } else {
> >> stop(paste(paste0("DRtype '",DRtype,"' not found."),
> >> "The following cell embeddings are available in this
> >> object:",
> >>
> >> paste0(SingleCellExperiment::reducedDimNames(x),collapse=", "),
> >> sep="\n "))
> >> }
> >> },
> >> where=.GlobalEnv)
> >>
> >>
> >> which gives the following error when SingleCellExperiment is loaded:
> >>
> >> Error in as.vector(x, "character") :
> >> cannot coerce type 'closure' to vector of type 'character'
> >>
> >>
> >> But if I just run that code, it doesn't give the error. I thought this
> >> might be due to where in the order of loading and attaching namespaces the
> >> hook is running, but changing the packageEvent event to "attach" makes no
> >> difference.
> >>
> >>
> >> Anyway, suppressing the message works, so I'm happy. Just wanted to
> >> report back on the partial success of doing it the cool way, in case
> >> anyone was interested.
> >>
> >>
> >> Thanks again!
> >>
> >> Brendan
> >>
> >>
> >> www.baderlab.org/BrendanInnes<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.baderlab.org_BrendanInnes&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=HwMn126h-7G4XmAqvYBr8lGjzQbgLqGq4-KkAOUH9r0&s=OIIsBqppQCVjbRlE5mpw0XnWEc-hiPwpjOCLNdiu4Mg&e=>
> >>
> >> ________________________________
> >> From: Martin Morgan <mtmorgan.b...@gmail.com>
> >> Sent: Wednesday, January 30, 2019 12:16:20 PM
> >> To: Brendan Innes; bioc-devel@r-project.org
> >> Subject: Re: [Bioc-devel] SetMethod to dispatch on class in unattached
> >> package
> >>
> >> A simple approach is to suppress the message (I think this is pragmatic,
> >> rather than dumb __) about unknown class (along with DESCRIPTION Suggests:
> >> Seurat)
> >>
> >> setGeneric("getGE", function(x) standardGeneric("getGE"))
> >>
> >> suppressMessages({
> >> setMethod("getGE", "seurat", function(x) Seurat::GetAssayData(x))
> >> })
> >>
> >> One fun thing to try is use hooks for package load; I would say that this
> >> is rarely used so may have surprising issues... Note the need to specify
> >> the location of the generic `PkgA::getGE` and that the method is defined
> >> in the global environment, rather than in the package environment, so
> >> would not have access to non-exported functions. The DESCRIPTION file has
> >> Suggests: Seurat
> >>
> >> Something along the lines of
> >>
> >> setGeneric("getGE", function(x) standardGeneric("getGE"))
> >>
> >> .onLoad <-
> >> function(...)
> >> {
> >> if ("Seurat" %in% loadedNamespaces()) {
> >> setMethod(
> >> getGE, "seurat",
> >> function(x) Seurat::GetAssayData(x)
> >> )
> >> } else {
> >> setHook(
> >> packageEvent("Seurat", "onLoad"),
> >> function(...) {
> >> setMethod(
> >> PkgA::getGE, "seurat",
> >> function(x) Seurat::GetAssayData(x),
> >> where = .GlobalEnv
> >> )
> >> }
> >> )
> >> }
> >> }
> >>
> >> Martin
> >>
> >> On 1/29/19, 9:27 PM, "Bioc-devel on behalf of Brendan Innes"
> >> <bioc-devel-boun...@r-project.org on behalf of
> >> brendan.in...@mail.utoronto.ca> wrote:
> >>
> >> Hi friendly Bioc gang! I'm struggling with what seems like a silly
> >> problem. I'm trying to write a simple wrapper S4 generic that accesses the
> >> data slot of various S4 objects (seurat and SingleCellExperiment objects).
> >> So the generic is:
> >>
> >> setGeneric("getGE",function(x) standardGeneric("getGE"))
> >>
> >>
> >> And the methods are:
> >>
> >> setMethod("getGE","seurat",
> >> function(x) Seurat::GetAssayData(x))
> >> setMethod("getGE","SingleCellExperiment",
> >> function(x) SingleCellExperiment::logcounts(x))
> >>
> >>
> >> Problem is that when I install the package, I get the warning
> >>
> >> > in method for �getGE� with signature �"seurat"�: no definition for
> >> class �seurat�
> >>
> >>
> >> This isn't surprising, since Seurat isn't imported, but I don't want
> >> the user to have to import it if their data is in a SingleCellExperiment
> >> object. The function still seems to work fine if I attach Seurat and load
> >> a seurat object, so I'm tempted to just suppress the error (but darned if
> >> I know how to do that either). Before I do something so rash, does anyone
> >> have a suggestion for a less dumb way to do this?
> >>
> >> Thanks so much!
> >> Brendan
> >>
> >>
> >>
> >>
> >> www.baderlab.org/BrendanInnes<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.baderlab.org_BrendanInnes&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=HwMn126h-7G4XmAqvYBr8lGjzQbgLqGq4-KkAOUH9r0&s=OIIsBqppQCVjbRlE5mpw0XnWEc-hiPwpjOCLNdiu4Mg&e=<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.baderlab.org_BrendanInnes&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=HwMn126h-7G4XmAqvYBr8lGjzQbgLqGq4-KkAOUH9r0&s=OIIsBqppQCVjbRlE5mpw0XnWEc-hiPwpjOCLNdiu4Mg&e=<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.baderlab.org_BrendanInnes&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=HwMn126h-7G4XmAqvYBr8lGjzQbgLqGq4-KkAOUH9r0&s=OIIsBqppQCVjbRlE5mpw0XnWEc-hiPwpjOCLNdiu4Mg&e=>>
> >>
> >> [[alternative HTML version deleted]]
> >>
> >>
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> _______________________________________________
> >> Bioc-devel@r-project.org mailing list
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=HwMn126h-7G4XmAqvYBr8lGjzQbgLqGq4-KkAOUH9r0&s=S3iJCS0wxwSgW8YdRpf-Oz4KO8Kkr-lSLX5yaziTTOA&e=
> > _______________________________________________
> > Bioc-devel@r-project.org mailing list
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=HwMn126h-7G4XmAqvYBr8lGjzQbgLqGq4-KkAOUH9r0&s=S3iJCS0wxwSgW8YdRpf-Oz4KO8Kkr-lSLX5yaziTTOA&e=
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
>
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
