[Bioc-sig-seq] Why are there non-imformative names() from GenomicFeatures:::exonsBy(...)?

[Steve Lianoglou]

Hi Hervé,

Thanks for the (*very*) thorough reply ... :-)

Just some random comments inline ...

> Just look at the output of str(exonsBy(txdb)) and try to spot all
> the "@ elementMetadata" lines to see what I mean.
>
> There is also a display challenge e.g. when a GRangesList object
> has values attached at 2 different levels (top-level values and
> element-level values).
...
> For these reasons, we decided to avoid using the GRangesList's
> top-level elementMetadata slot in the GenomicFeatures package.

Once we get our own R2D2 like 3d/hologram displays/projectors, perhaps
revisiting this issue would be fruitful ... :-)

>> Yes, that's what I'm asking -- I'd like functions like exonsBy, cdsBy,
>> transcripts, exons, etc. to be S4-ized (and allowed to take an '...'
>> parameter).
>
> Sounds good to me. I'll wait a couple of days before I make the change
> so people have time to comment/object if they want.

Thank you.

> Right, we don't provide anything to extract stuff from the metadata
> table (something like your getMetadata() extractor). But we could if
> people find this useful. Right now, they can do:
>
>  dbReadTable(GenomicFeatures:::txdbConn(txdb), "metadata")
>
> and then do standard data.frame manipulation (like row subsetting)
> on the result.
>
> As for your setMetadata(), I can see how people might want to add
> their own metadata to the TranscriptDb object but this breaks the
> "TranscriptDb objects are read-only" paradigm. Here is a suggestion:
> if the user already knows those extra metadata at db creation time,
> maybe we could add an extra argument to the makeTranscriptDbFrom*()
> family so s/he can pass them when s/he makes the object. Would that
> be good enough? What kind of metadata do you want to add to your
> TranscriptDb objects?

I wasn't expecting a user to want to set any metadata just yet. The
setMetadata(...) function just came along w/ the copy/paste from an
other package I was making that also stored metadata in the same way.
There I used setMetadata() just to make my own (internal) code cleaner
... the getMetadata(...) IMHO *is* actually more useful to the
consumer of the package, though.

The only reason I linked to that page github page, though, was that I
thought it might be helpful to you if I gave you a list of functions I
identified in the GenomicFeatures package that I trampled/S4-ized, not
to tell you guys how to design your packages ... sorry if it came
across that way :-)

Thanks again,
-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