[Bioc-devel] recalling methods

[Michael Love]

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.michael at gene.com>
wrote:

>
>
> On Sat, Dec 6, 2014 at 9:23 AM, Wolfgang Huber <whuber at 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 <
>> michaelisaiahlove at gmail.com> wrote:
>> >
>> > nice. I will play around with this. thanks Gabe!
>> >
>> > On Fri, Dec 5, 2014 at 6:37 PM, Gabe Becker <becker.gabe at 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.michael at 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
>> >>> <michaelisaiahlove at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> On Thu, Dec 4, 2014 at 4:01 PM, Michael Lawrence
>> >>>> <lawrence.michael at 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 <
>> >>>> michaelisaiahlove at 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 at r-project.org mailing list
>> >>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>        [[alternative HTML version deleted]]
>> >>>
>> >>> _______________________________________________
>> >>> Bioc-devel at r-project.org mailing list
>> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Computational Biologist
>> >> Genentech Research
>> >
>> > _______________________________________________
>> > Bioc-devel at r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>

	[[alternative HTML version deleted]]