[BioC] no summary of GOHyperGResult

Robert M. Flight rflight79 at gmail.com
Fri Jul 9 16:36:03 CEST 2010


Thanks to both Martin and James for the suggestions, but I give up.
I've tried adding the stuff to the NAMESPACE file that Martin
suggested, and that doesn't seem to work. However, I can't figure out
where or how I would add the kluge that James suggests, as this isn't
required in GOstats and it figures it out fine.

I know I can access what I need using the slots of the object, I just
figured that I would use the methods already available.

For the record, determining how to go from a simple function with
"require" to a package that has access to the right functions and
methods is a real pain, and the documentation is none too stupendous
on how to do that.

Thanks,

-Robert

Robert M. Flight, Ph.D.
Bioinformatics and Biomedical Computing Laboratory
University of Louisville
Louisville, KY

PH 502-852-0467
EM robert.flight at louisville.edu
EM rflight79 at gmail.com

Williams and Holland's Law:
       If enough data is collected, anything may be proven by
statistical methods.



On Thu, Jul 8, 2010 at 18:42, Martin Morgan <mtmorgan at fhcrc.org> wrote:
> On 07/08/2010 01:56 PM, Robert M. Flight wrote:
>> This strikes me as really weird (and annoying) behavior.
>>
>> I have a GOHyperGResult, calculated using GOstats and Category from
>> which I want to obtain a summary. This summary call is within a
>> function, that I tested time and time again to verify that it was
>> working (worked yesterday, haven't changed my setup). However, now,
>> whenever I call summary on the GOHyperGResult in my function, I get
>> this (via browser(expr=TRUE) just before where I would actually use
>> it):
>>
>> R> summary(GOHyperGResultObject)
>>
>>        Length          Class           Mode
>>              1 GOHyperGResult             S4
>>
>> However, showMethods("summary") gives the following:
>>
>> Function: summary (package base)
>> object="AnnDbBimap"
>> object="ANY"
>> object="Bimap"
>> object="DBIObject"
>> object="GOHyperGResult"
>> object="HyperGResultBase"
>> object="KEGGHyperGResult"
>> object="LinearMResultBase"
>> object="PFAMHyperGResult"
>> object="SQLiteConnection"
>> object="SQLiteDriver"
>> object="SQLiteResult"
>>
>> When outside the function (in the base workspace), I get the actual
>> summary I am after. However, when I check if there is a difference in
>> showMethods("summary"), I see the same list:
>> Function: summary (package base)
>> object="AnnDbBimap"
>> object="ANY"
>> object="Bimap"
>> object="DBIObject"
>> object="GOHyperGResult"
>> object="HyperGResultBase"
>> object="KEGGHyperGResult"
>> object="LinearMResultBase"
>> object="PFAMHyperGResult"
>> object="SQLiteConnection"
>> object="SQLiteDriver"
>> object="SQLiteResult"
>>
>> The object in the base workspace is a save of the object being
>> generated in my function, so I know it is not because they are
>> different objects. I thought this might due to installing a new
>> package (KEGGgraph was the last one I installed), but even after
>> removing and restarting the same behavior continues.
>>
>> If anyone could shed some light on this behavior, I would really,
>> really appreciate it, because I can't see why this is happening. My
>> function is in a package, do I need to explicitly import the "summary"
>> method from GOstats in the NAMESPACE? I already have GOstats in the
>> require, and it loads the package.
>
> If your function is in a package, then yes, you should in the
> DESCRIPTION file
>
>  Imports: GOstats
>
> and
>
>  importClassesFrom(GOstats, GOHyperGResult)
>  importMethodsFrom(GOstats, summary)
>
> It sounds like your package has code
>
>  require(GOstats)
>
> but that's not what you want to do -- it'll attach GOstats to the search
> path, but you want GOstats, or at least the summary methods defined in
> GOstats, available to your package without relying on the structure of
> the (user modifiable) search path.
>
> I don't know the details behind Jim's suggestion, but a certain amount
> of water has passed under the bridge since then and I'd be interested in
> knowing whether those contortions are actually necessary in an
> appropriately structured package.
>
> Martin
>
>
>>
>> Cheers,
>>
>> -Robert
>>
>> R version 2.11.1 (2010-05-31)
>> i386-pc-mingw32
>>
>> locale:
>> [1] LC_COLLATE=English_United States.1252
>> [2] LC_CTYPE=English_United States.1252
>> [3] LC_MONETARY=English_United States.1252
>> [4] LC_NUMERIC=C
>> [5] LC_TIME=English_United States.1252
>>
>> attached base packages:
>> [1] grid      stats     graphics  grDevices utils     datasets  methods
>> [8] base
>>
>> other attached packages:
>>  [1] org.Mm.eg.db_2.4.1    GO.db_2.4.1           categoryCompare_0.1-1
>>  [4] biocGraph_1.10.0      Rgraphviz_1.26.0      hwriter_1.2
>>  [7] GOstats_2.14.0        RSQLite_0.9-1         DBI_0.2-5
>> [10] graph_1.26.0          Category_2.14.0       AnnotationDbi_1.10.1
>> [13] Biobase_2.8.0
>>
>> loaded via a namespace (and not attached):
>>  [1] annotate_1.26.0    genefilter_1.30.0  geneplotter_1.26.0 GSEABase_1.10.0
>>  [5] RBGL_1.24.0        RColorBrewer_1.0-2 splines_2.11.1     survival_2.35-8
>>  [9] tools_2.11.1       XML_3.1-0          xtable_1.5-6
>>
>> Robert M. Flight, Ph.D.
>> Bioinformatics and Biomedical Computing Laboratory
>> University of Louisville
>> Louisville, KY
>>
>> PH 502-852-0467
>> EM robert.flight at louisville.edu
>> EM rflight79 at gmail.com
>>
>> Williams and Holland's Law:
>>        If enough data is collected, anything may be proven by
>> statistical methods.
>>
>> _______________________________________________
>> Bioconductor mailing list
>> Bioconductor at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/bioconductor
>> Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor
>
>
> --
> Martin Morgan
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>



More information about the Bioconductor mailing list