[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:

  pkg::fun()

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.

/Henrik


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