For what it's worth, my package (LOLA) was one that used as.list on a
GRanges or GRangesList, and those calls were broken by changes to devel.
Since I was also pushing changes at the time, I assumed the devel build
errors were due to my updates -- I spent quite a bit of time trying to
figure out what was wrong before I realized this breakage was not caused
by my updates, but by upstream changes in GRanges...eventually I tracked
down errors to as.list (and ultimately, found other errors, which we
discussed earlier on this list), but my conclusion from this was that,
from my perspective, using the deployed bioc devel as a way to test for
what refactoring will break doesn't seem like the ideal way to go -- I
assumed that generally, other package changes wouldn't typically be
pushed that would break my package's build, so it devalued the role of
the dev builds and reduced my confidence in using that (now when I see
error I may assume it's something else, and wait a few days, instead of
diving right in to try to solve the problem).
I like the idea of temporarily restoring as.list with a deprecation
message -- also, as a general development philosophy going forward in
terms of testing on devel. This would have saved me a lot of time
troubleshooting in this instance.
Just my 2 cents.
-Nathan
On 02/16/2018 02:57 AM, Bernat Gel wrote:
Hi Hervé and others,
Thanks for the responses.
I woudn't call as.list() of a GRanges an "obscure behaviour" but more
a "works as expected, even if not clearly documented" behaviour.
In any case I can change the code to as(gr, "GRangesList") as suggested.
Thanks again for the responses and discussion :)
Bernat
*Bernat Gel Moreno*
Bioinformatician
Hereditary Cancer Program
Program of Predictive and Personalized Medicine of Cancer (PMPPC)
Germans Trias i Pujol Research Institute (IGTP)
Campus Can Ruti
Carretera de Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona, Spain
Tel: (+34) 93 554 3068
Fax: (+34) 93 497 8654
08916 Badalona, Barcelona, Spain
b...@igtp.cat <mailto:b...@igtp.cat>
www.germanstrias.org <http://www.germanstrias.org/>
<http://www.germanstrias.org/>
El 02/15/2018 a las 11:19 PM, Hervé Pagès escribió:
On 02/15/2018 01:57 PM, Michael Lawrence wrote:
On Thu, Feb 15, 2018 at 1:45 PM, Hervé Pagès <hpa...@fredhutch.org
<mailto:hpa...@fredhutch.org>> wrote:
On 02/15/2018 11:53 AM, Cook, Malcolm wrote:
Hi,
Can I ask, is this change under discussion in current
release or
so far in Bioconductor devel only (my assumption)?
Bioconductor devel only.
> On 02/15/2018 08:37 AM, Michael Lawrence wrote:
> > So is as.list() no longer supported for GRanges objects?
I have found it
> > useful in places.
>
> Very few places. I found a dozen of them in the entire
software repo.
However there are probably more in the wild...
What as.list() was doing on a GRanges object was not documented.
Relying
on some kind of obscure undocumented feature is never a good idea.
There's just too much that is documented implicitly through
inherited behaviors, or where we say things like "this data
structure behaves as one would expect given base R". It's not fair
to claim that those features are undocumented. Our documentation is
not complete enough to use it as an excuse.
It's not fair to suggest that this is a widely used feature either.
I've identified all the places in the 1500 software packages where
this was used, and, as I said, there were very few places. BTW I
fixed most of them but my plan is to fix all of them. Some of the
code that is outside the Bioc package corpus might be affected but
it's fair to assume that this will be a very rare occurence. This can
be mitigated by temporary restoring as.list() on GRanges, with a
deprecation message, and wait 1 more devel cycle to replace it with
the new behavior. I chose to disable it for now, on purpose, so I can
identify packages that break (the build report is a great tool for
that) and fix them.
I'm not using the fact that as.list() on a GRanges is not documented
as an excuse for anything. Only to help those with concerns to
relativize and relax.
H.
> Now you should use as.list(as(gr, "GRangesList")) instead.
> as.list() was behaving inconsistently on IRanges and
GRanges objects,
> which is blocking new developments. It will come back with
a consistent
> behavior. More generally speaking IRanges and GRanges will
behave
> consistently as far as their "list interpretation" is
concerned.
Can we please be assured to be reminded of this prominently in
release notes?
The changes will be announced and described on this list and in the
NEWS files of the IRanges and GenomicRanges packages.
H.
Thanks!
~malcolm
-- Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org <mailto:hpa...@fredhutch.org>
Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
_______________________________________________
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
