[Bioc-devel] Naming and namespace collisions for commonly-named functions

Henrik Bengtsson henrik.bengtsson at gmail.com
Tue Jan 24 22:09:09 CET 2017

A few times I'd wish there was a way to support:


while _not_ "exposing" fun() on the search() path when attaching pkg.
Although it would be part of the public / exported API, the only way
to call the function would be via pkg::fun().  This would cover Sean's
use case.  It would also help cluttering up what's on the search()
path, especially for rarely used functions, while still making them
publicly available.


On Tue, Jan 24, 2017 at 7:31 AM, Martin Morgan
<martin.morgan at roswellpark.org> wrote:
> On 01/24/2017 10:19 AM, Sean Davis wrote:
>> Hi, all.
>> I am curious about what folks think about naming conventions for commonly
>> named functions, some of which are so common that even establishing a
>> generic would be difficult because of different use cases.  Examples
>> include things like “filter”.  One possibility is to use the Google Sheets
>> approach and prefix function names with ‘gs_’.  The alternative approach
>> is
>> to use the more common names and rely on folks to disambiguate if more
>> than
>> one package that shares the name is loaded.  The former has the advantage
>> of being more novice-friendly, but the latter is likely to sit nicely with
>> developers and regular R/Bioc users since the functions will be commonly
>> used.  Any thoughts one way or the other?
> I think that if functions have semantic differences either in argument or
> return values then one should choose a different name, definitely.
> Even if functions have similar semantics, it's often valuable to emphasize
> the unique features being offered by your version, e.g., bplapply() points
> the user to the help page where BPPARAM is a explicit argument.
> And a prefix means that the script works always, not just when one remembers
> to disambiguate in the session where the conflicting package was not loaded
> (hence no reminder that disambiguation was necessary).
> Martin
>> Thanks,
>> Sean
>>         [[alternative HTML version deleted]]
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> This email message may contain legally privileged and/or...{{dropped:2}}
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

More information about the Bioc-devel mailing list