Somewhat related to this topic, some folks made this package: https://github.com/hilaryparker/explainr It could be related to Wolfgang's idea of "learning" which methods are more important, its just that people would have to write the explanation. Then a new user can "learn" about it.
On Mon, Apr 6, 2015 at 11:08 AM, Michael Love <michaelisaiahl...@gmail.com> wrote: > I just noticed in the newsletter [1] that Martin fixed this in R-devel / R > 3.2 > >> methods(class="GenomicRanges") > [1] != [ [<- %in% > < > ... > > thanks Martin! > > [1] > http://www.bioconductor.org/help/newsletters/2015_April/#new-and-noteworthy > > On Sat, Dec 6, 2014 at 5:32 PM, Michael Lawrence <lawrence.mich...@gene.com> > wrote: > >> >> >> On Sat, Dec 6, 2014 at 9:23 AM, Wolfgang Huber <whu...@embl.de> wrote: >> >>> >>> Also some interest on our side to contribute. >>> Perhaps in particular the rendering a useful index (or graph) of man >>> pages on the fly in HTML / graphically. >>> >>> >> Great, that's the sort of thing I had in mind. >> >> >>> Is it too ambitious to “learn” which methods are most important for >>> objects of a particular class from analysing (running) a large code base >>> (or even injecting a hook to that effect into a user’s R)? >>> >>> >> It's a good idea and one that Eclipse and other IDEs use for >> auto-completion. We'd just have to find the right codebase, i.e., something >> with a lot of end-user analysis code, instead of infrastructure. >> >> Wolfgang >>> >>> >>> >>> >>> >>> >>> > On Dec 6, 2014, at 1:19 GMT+1, Michael Love < >>> michaelisaiahl...@gmail.com> wrote: >>> > >>> > nice. I will play around with this. thanks Gabe! >>> > >>> > On Fri, Dec 5, 2014 at 6:37 PM, Gabe Becker <becker.g...@gene.com> >>> wrote: >>> >> Hey guys, >>> >> >>> >> Surgically removed from promptClass: >>> >> >>> >> classInSig <- function(g, where, cl) { >>> >> cl %in% unique(unlist(findMethods(g, where)@signatures)) >>> >> } >>> >> genWithClass <- function(cl, where) { >>> >> allgen <- getGenerics(where = where) >>> >> ok <- as.logical(unlist(lapply(allgen, classInSig, cl = cl, >>> >> where = where))) >>> >> allgen[ok] >>> >> } >>> >> >>> >>> genWithClass("IRanges", find(classMetaName("IRanges"))) >>> >> [1] "c" "coerce" "end<-" "gaps" >>> "intersect" >>> >> [6] "isNormal" "names<-" "names" "pgap" >>> >> "pintersect" >>> >> [11] "psetdiff" "punion" "reduce" "reverse" >>> "setdiff" >>> >> [16] "start<-" "start" "threebands" "union" >>> >> "updateObject" >>> >> [21] "update" "width<-" "width" >>> >> >>> >> >>> >> For semantic guessing of which ones will be useful, I've got nothing >>> (for >>> >> now). >>> >> >>> >> ~G >>> >> >>> >> On Fri, Dec 5, 2014 at 11:28 AM, Michael Lawrence >>> >> <lawrence.mich...@gene.com> wrote: >>> >>> >>> >>> Cool. I see hypertext as being useful here, because the generics and >>> >>> classes form an intricate and sometimes ambiguous web, especially when >>> >>> multiple inheritance and dispatch are involved. I think we should >>> first >>> >>> build better tooling for introspecting S4 and for graph-based >>> modeling and >>> >>> analysis of S4 architecture. For example, could we statically detect >>> >>> whether a dispatch ambiguity exists, knowing all of the methods and >>> >>> classes? And based on that build one or more end-user UIs? >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Dec 5, 2014 at 11:05 AM, Michael Love >>> >>> <michaelisaiahl...@gmail.com> >>> >>> wrote: >>> >>> >>> >>>> On Thu, Dec 4, 2014 at 4:01 PM, Michael Lawrence >>> >>>> <lawrence.mich...@gene.com> wrote: >>> >>>>> >>> >>>>> I think this gets at the heart of at least one of the usability >>> issues >>> >>>> in Bioconductor: interface discoverability. Many simpler command line >>> >>>> tools >>> >>>> have a single-faceted interface for which it is easy to enumerate a >>> list >>> >>>> of >>> >>>> features. There's definitely room for better ways to interrogate our >>> >>>> object-oriented APIs, but it's challenging. Essentially we need a way >>> >>>> for >>> >>>> the user to ask "what can I do with this object?". Yes, we need >>> better >>> >>>> introspection utilities, but we also need to integrate the query with >>> >>>> documentation. In other words, we need a more dynamic, more fluid >>> help >>> >>>> system, oriented around S4. >>> >>>>> >>> >>>> >>> >>>> I would be interested in working on this. A minimal goal for me is a >>> >>>> function that just returns a character vector of the names of the >>> >>>> generics defined for the object. Filtering that down to give methods >>> >>>> which are "likely relevant" using the documentation will definitely >>> be >>> >>>> a bigger challenge. >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Thu, Dec 4, 2014 at 9:56 AM, Michael Love < >>> >>>> michaelisaiahl...@gmail.com> wrote: >>> >>>>>> >>> >>>>>> I was thinking about a request from someone at Bioc2014 (I can't >>> >>>>>> remember at the moment) >>> >>>>>> >>> >>>>>> As an end-user, if I have an object x, how can I *quickly* recall >>> the >>> >>>>>> main methods for that? As in, without breaking my flow and going to >>> >>>>>> ?myClass or help("myClass-class"). Suppose x is a GRanges, how can >>> I >>> >>>>>> remember that there is a method called narrow() which works on x? >>> >>>>>> >>> >>>>>> showMethods(classes=class(x)) will print out a huge list for many >>> >>>>>> complex Bioc classes. And printTo=FALSE turns this huge list into >>> an >>> >>>>>> unhelpful character vector, e.g.: >>> >>>>>> >>> >>>>>> head(showMethods(classes="GRanges",printTo=FALSE),8) >>> >>>>>> [1] "" "Function \".asSpace\":" >>> >>>>>> [3] " <not an S4 generic function>" "" >>> >>>>>> [5] "Function \".linkToCachedObject<-\":" " <not an S4 generic >>> >>>> function>" >>> >>>>>> [7] "" "Function >>> >>>>>> \".replaceSEW\":" >>> >>>>>> >>> >>>>>> any ideas? >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> Bioc-devel@r-project.org mailing list >>> >>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >>>>> >>> >>>>> >>> >>>> >>> >>> >>> >>> [[alternative HTML version deleted]] >>> >>> >>> >>> _______________________________________________ >>> >>> Bioc-devel@r-project.org mailing list >>> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Computational Biologist >>> >> Genentech Research >>> > >>> > _______________________________________________ >>> > Bioc-devel@r-project.org mailing list >>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >>> _______________________________________________ >>> Bioc-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>> >> >> > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
