How about mentioning the existing generics in BiocGenerics as a basis to
build upon? RG has mentioned that competing implementations are not bad,
and I see the point of a healthy marketplace for ideas, but it's easier to
benchmark methods that work similarly. This does not constrain developers
unnecessarily, in fact it usually does the opposite.
something like:
"If a generic function is defined in the BiocGenerics package, and your
package has a function that does something similar, please adapt your
package to use the generic.
If your package produces output that could be transformed or placed into a
foundational Bioconductor class (e.g. an eSet, GRanges, DataFrame, or
SummarizedExperiment), please adapt your package to inherit from, or coerce
to, these class signatures.
Adhering to the preceding guidelines will ensure that users of your package
have access to thousands of methods, from hundreds of packages in
Bioconductor, on CRAN and elsewhere, which define these generic methods and
expect these classes as input."
On the one hand, it's obvious to anyone with an OOP background that using
libraries and inheriting from existing classes is the right way to do
things. On the other hand, not everyone writing R packages has necessarily
worked on big C++ or Java projects.
Just my $0.02, but I sure wish I had realized where the correct balance
between new and old lay, from the beginning. Modeling my code on Sean
Davis' created some very good habits, but I didn't go as far as I should
have. In recent development, I try to figure out how to take advantage
especially of Ranges-derived functionality (for Rle and sparseVector
columns) and the ability of SummarizedExperiments to encapsulate sparse
matrices, so I almost never have to reimplement something that's already
been implemented by people intimately familiar with R internals. This has
saved me lots of development time, and increased runtime performance a
great deal. (I was surprised to discover that even experienced package
developers sometimes reinvent the wheel.)
Reinventing the wheel isn't necessarily bad, but any new implementation
should satisfy certain basic assumptions ("round", "rolls smoothly",
"attaches to existing axles") for maximum market penetration :-)
On Fri, Feb 22, 2013 at 8:27 AM, Martin Morgan <[email protected]> wrote:
> On 02/22/2013 07:08 AM, Wolfgang Huber wrote:
>
>>
>> I would like to suggest clarification of the information in the "Package
>> Guidelines" [1] and the "Package Submission" [2] pages.
>>
>> 1. Information that is actually of type "guideline" is (only) stated on
>> the
>> submission page, which is confusing. Shouldn't one page describe the
>> applied
>> criteria, and the other the submission procedure?
>>
>> 2. We state: "Packages should also conform to the following: Use S4
>> classes
>> and methods.". This is vague and confusing. I think what it should say is
>> that *existing* S4 classes and generic functions, and existing methods,
>> should be re-used. What many developers seem to interpret this as is that
>> they should come up with lots of their own, new, ideosyncratic S4 classes
>> and
>> methods. Which mostly only adds overhead and complexity, and rarely any
>> benefit. I would like to suggest removing that statement, or clarifying
>> it.
>>
>
> I addressed this specific issue by changing the package-submission text to
>
> Use existing S4 classes and generic functions; see the Package Guidelines
> for details on appropriate use.
>
> and the package-guideline text to
>
> Re-use existing S4 classes and generics where possible. This encourages
> interoperability and simplifies your own package development. If your data
> requires a new representation or function, carefully design an S4 class or
> generic so that other package developers with similar needs will be able to
> re-use your hard work, and so that users of related packages will be able
> to seamlessly use your data structures. Do not hesitate to ask on the
> Bioc-devel mailing list for advice.
>
> We will revisit the submission / guideline pages over the next several
> days, but additional specific issues are certainly welcome from you or
> others...
>
> Martin
>
>
>
>> Best wishes Wolfgang
>>
>>
>> [1]
>> http://www.bioconductor.org/**developers/package-guidelines/<http://www.bioconductor.org/developers/package-guidelines/>[2]
>> http://www.bioconductor.org/**developers/package-submission/<http://www.bioconductor.org/developers/package-submission/>
>> ______________________________**_________________
>> [email protected]
>> mailing list
>> https://stat.ethz.ch/mailman/**listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>>
>>
>
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>
>
> ______________________________**_________________
> [email protected] mailing list
> https://stat.ethz.ch/mailman/**listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>
--
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper<http://cancerres.aacrjournals.org/content/31/9/1173.full.pdf>
[[alternative HTML version deleted]]
_______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
