On Mon, Feb 7, 2011 at 7:38 PM, Steve Lianoglou <
mailinglist.honeypot@gmail.com> wrote:

> On Mon, Feb 7, 2011 at 2:58 PM, Martin Morgan <mtmorgan@fhcrc.org> wrote:
> > On 02/07/2011 10:36 AM, Steve Lianoglou wrote:
> >> On Mon, Feb 7, 2011 at 1:08 PM, Michael Lawrence
> >> <lawrence.michael@gene.com> wrote:
> >>> On Mon, Feb 7, 2011 at 9:42 AM, Steve Lianoglou
> >>> <mailinglist.honeypot@gmail.com> wrote:
> [snip]
> >> I'm curious what the folks at The Hutch had in mind with respect to
> >> how they envisioned the `elementMetadata` vs. `values` api to play
> >> out?
> >
> > 'values' for GenomicRanges.
>
> Ok ... obviously it's your decision to make, but isn't it a bit
> confusing to settle on values() for GenomicRanges objects and
> elementMetadata() for IRanges when both "things" represent the same
> "thing"? What's the motivation for that?
>
>
Although IRanges defines 'values' as a synonym for 'elementMetadata', in my
opinion elementMetadata is the preferred term. The term 'values' is just too
generic to work in general. For example, if one has an IntegerList, what are
the values? The elements or the element metadata? What would a naive user
think?

The purpose of GenomicRanges was to annotate a sequence of ranges with
chromosome, strand, and other data. Since the purpose was annotation,
values() might be easier to interpret? The values are certainly still
metadata.. on the elements. The only good thing about values vs.
elementMetadata is that it's shorter. If the `$` method were supported on
GenomicRanges, it wouldn't matter nearly as much.


> >>> But yea, your idea for 'c' is convenient. Care to submit a patch?
> >>
> >> I'd be happy to ... maybe just as soon as we get a green light from
> >> The Hutch (w.r.t utility and param. name)?
> >
> > yes sounds good.
>
> Given the values vs. elementMetadata thing above, what should the
> appropriate name for the parameter be that we're talking about here?
>
> Would the c,GenomicRanges function then have a different name for this
> parameter (.ignoreValues) as compared and to the c,IRanges(or anything
> else) (.ignoreElementMetadata)?
>
> > Is this what 'recursive' is supposed to regulate (with
> > the current behavior recursive = TRUE, despite the signature?).
>
> I'm not sure. I'm having a hard time imagining how recursive=TRUE vs.
> FALSE would actually behave in the c()-context.
>
> Maybe it would make more sense to check for it to be !missing then
> give a warning telling the user it's not being handled, eg:
>
> if (!missing(recursive)) {
>  warning("`recursive` parameter is ignored ...")
> }
>
> (or some such)
>
>
Yea, that's generally what's done. GenomicRanges is a flat structure, so
recursive has no meaning. Sure, it is composed of slots, but it's
non-recursive.


>
>
> I'm
> > recognizing the more-or-less fractal nature of IRanages, and the
> > multiple elementMetadata locations in GRanges (on ranges(), on values(),
> > as well as values(ranges()), values(values()), etc.)
>
> I never thought about the values() of the ranges() of a GenomicRanges
> object actually ...
>
> While we're at it, I guess there should be a "values" method defined
> in GenomicRanges that just aliases its elementMetadata() function:
>
> setMethod("values", "GenomicRanges", function(x, ...) elementMetadata(x,
> ...)
>
> since elementMetadata,GenomicRanges does some `rownames` bookkeeping
> before it passes down to the elementMetadata,Sequence method.
>
>
This is exactly what the "values" method for "Sequence" does, as defined in
IRanges.


> Thanks,
> -steve
>
> --
> Steve Lianoglou
> Graduate Student: Computational Systems Biology
>  | Memorial Sloan-Kettering Cancer Center
>  | Weill Medical College of Cornell University
> Contact Info: http://cbio.mskcc.org/~lianos/contact
>

	[[alternative HTML version deleted]]

