I didn't mean to imply that the situation can't be improved, but I still
believe costs and benefits of changes of this sort are hard to reckon.  For
me a real unknown is the added managerial cost of centralization of generic
definitions.  If lots of people have write privilege over the generic
repository, I can imagine nontrivial confusions; if management is delegated
to an individual or small group, there can be discouraging bottlenecks.  Our
ad hoc approach has worked but with blemishes.  I'd like some evidence that
a more systematic approach would have fewer blemishes.  In theory it would,
but the practical solution requires some decisions on consensus and process
that will be costly to make correctly.  Is there a language in which the
problem area has been addressed in a more satisfactory way?

My gut reaction is that if people really wanted to smooth things out with
bio-oriented generics, they'd agree with one another that the generic should
have a specific form, and ask a Biobase maintainer to have it defined in
Biobase.  Could we do some case studies with this approach -- "strand" might
be a reasonable initial case study -- and then decide on whether an
additional package will be better?

On Mon, Sep 26, 2011 at 10:18 AM, Kasper Daniel Hansen <
kasperdanielhansen@gmail.com> wrote:

> Let me restart this discussion.
>
> There are a number of classes that could be considered core
> Bioconductor classes such as phenoData.  I agree that these classes
> are better handled with our current setup.  It would make little sense
> to separate the IRanges class into a separate package for example.
> There are possibly some exceptions, I would like the phenoData class
> from Biobase to be more widely used in the sequencing packages, but
> that will happen over time (and it might already have happened to some
> extent).
>
> My suggestion is really not about the classes, it is about the generics.
>
> I believe that there are many cases where multiple (perhaps competing)
> packages would like to have methods called XX.  For example, Martin
> mentioned strand, which I disagree is necessarily best handled by
> GenomicRanges.  I could see many usecases for a strand generic that
> has nothing to do with GenomicRanges.  By gathering those into a small
> package with almost no content except the generics we allow
>  * more code reuse and better handling of loading several packages.
> For example, I am currently developing a package where I want to have
> a generic that I just found out is also defined by oligoClasses.  Now,
> my package has nothing to do with oligoClasses, so I don't
> particularly want to load/import this package just to get the generic.
>  This has happened to me many times.
>  * better handling of all the functions from "base R" that we always
> end up with defining as generics in Bioconductor (for example, all the
> ones from IRanges)
>  * we also provide an easy way to get an overview of core
> Bioconductor methods that package developers ought to consider
> supporting.  For example, I think sampleNames() should be supported by
> most (all?) classes dealing with data.  Having a sampleNames generic
> in a basic package would make it easy for new developers to see that
> this is a method they might consider supporting.
>
> Now, Vince is raising the issue that what we have now works well.  My
> opinion is that as Bioconductor grows, I see this becoming a possible
> larger problem which is really just caused by how R handles generics
> (not that I have any great idea on how this could be handled better).
> We should of course think about how the signature of the generic is
> defined.  I also think that doing this should be relatively little
> work.
>
> Kasper
>

	[[alternative HTML version deleted]]

