Style question

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Style question

Ronald Barry
Greetings,
  When using a 'foreign' function (from another package, say function
'whatever' from package 'foo'), you can of course just require the package
and then just have

whatever(...)

in your code.  However, I would like to use the

foo::whatever(...)

form instead, just for documentation purposes (easier to see what function
comes from what package).  Is there a cost to doing this?  Is it considered
good or bad style?  Thanks.

Ron Barry

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

Hervé Pagès
Hi Ronald,

On 05/28/2014 01:46 PM, Ronald Barry wrote:

> Greetings,
>    When using a 'foreign' function (from another package, say function
> 'whatever' from package 'foo'), you can of course just require the package
> and then just have
>
> whatever(...)
>
> in your code.  However, I would like to use the
>
> foo::whatever(...)
>
> form instead, just for documentation purposes (easier to see what function
> comes from what package).  Is there a cost to doing this?  Is it considered
> good or bad style?  Thanks.

Even more important than choosing between whatever(...)
or foo::whatever(...), you should import that function
from the foo package by putting

   importFrom(foo, whatever)

or

   import(foo)

in your NAMESPACE file.

The 1st form also kind of document what function comes from what
package.

Note that you'll also need to have foo in the Depends or Imports field
of your DESCRIPTION file. Which field is appropriate depends on whether
or not you want foo to show up in the user's search path when s/he loads
your package with 'library(yourpackage)'.

Cheers,
H.

>
> Ron Barry
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

--
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: [hidden email]
Phone:  (206) 667-5791
Fax:    (206) 667-1319

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

hadley wickham
> Even more important than choosing between whatever(...)
> or foo::whatever(...), you should import that function
> from the foo package by putting
>
>   importFrom(foo, whatever)
>
> or
>
>   import(foo)
>
> in your NAMESPACE file.
>
> The 1st form also kind of document what function comes from what
> package.
>
> Note that you'll also need to have foo in the Depends or Imports field
> of your DESCRIPTION file. Which field is appropriate depends on whether
> or not you want foo to show up in the user's search path when s/he loads
> your package with 'library(yourpackage)'.

Except that if you do foo::whatever() you don't need to explicitly
import the function.

Hadley


--
http://had.co.nz/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

Hervé Pagès
Hi Hadley,

On 05/30/2014 07:06 AM, Hadley Wickham wrote:

>> Even more important than choosing between whatever(...)
>> or foo::whatever(...), you should import that function
>> from the foo package by putting
>>
>>    importFrom(foo, whatever)
>>
>> or
>>
>>    import(foo)
>>
>> in your NAMESPACE file.
>>
>> The 1st form also kind of document what function comes from what
>> package.
>>
>> Note that you'll also need to have foo in the Depends or Imports field
>> of your DESCRIPTION file. Which field is appropriate depends on whether
>> or not you want foo to show up in the user's search path when s/he loads
>> your package with 'library(yourpackage)'.
>
> Except that if you do foo::whatever() you don't need to explicitly
> import the function.

There is at least one subtle consequence to keep in mind when doing
this. Of course, whatever choice you make, if the whatever() function
moves to a different package, this breaks your package.
However, if you explicitly import the function, your package will
break at load-time (which is good) and you'll only have to modify
1 line in the NAMESPACE file to fix it. But if you do foo::whatever(),
your package won't break at load-time, only at run-time. Also you'll
have to edit all the calls to foo::whatever() to fix the package.

Probably not a big deal, but in an environment like Bioconductor where
infrastructure classes and functions can be shared by hundreds of
packages, having people use foo::whatever() in a systematic way would
probably make maintenance a little bit more painful than it needs to
be when the need arises to reorganize/refactor parts of the
infrastructure. Also, the ability to quickly grep the NAMESPACE
files of all BioC packages to see who imports what is very convenient
in this situation.

Cheers,
H.

>
> Hadley
>
>

--
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: [hidden email]
Phone:  (206) 667-5791
Fax:    (206) 667-1319

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

hadley wickham
> There is at least one subtle consequence to keep in mind when doing
> this. Of course, whatever choice you make, if the whatever() function
> moves to a different package, this breaks your package.
> However, if you explicitly import the function, your package will
> break at load-time (which is good) and you'll only have to modify
> 1 line in the NAMESPACE file to fix it. But if you do foo::whatever(),
> your package won't break at load-time, only at run-time. Also you'll
> have to edit all the calls to foo::whatever() to fix the package.
>
> Probably not a big deal, but in an environment like Bioconductor where
> infrastructure classes and functions can be shared by hundreds of
> packages, having people use foo::whatever() in a systematic way would
> probably make maintenance a little bit more painful than it needs to
> be when the need arises to reorganize/refactor parts of the
> infrastructure. Also, the ability to quickly grep the NAMESPACE
> files of all BioC packages to see who imports what is very convenient
> in this situation.

OTOH, I think there's a big benefit to being able to read package code
and instantly know where a function comes from.

Personally, I found this outweighs the benefits that you outline:

* functions rarely move between packages, and gsubbing for pkga:foo to
pkgb:foo isn't hard
* it's not that much hard to grep for pkg::foo in R/* than it is to
grep NAMESPACE

Hadley

--
http://had.co.nz/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

Gabriel Becker
This isn't likely to make much difference in most cases, but calling a
function via :: can incur up to about twice the overhead on average
compared to calling an imported function

> fun1
function ()
file_ext("text.txt")
<environment: namespace:imptest>
> fun2
function ()
tools::file_ext("text.txt")
<environment: namespace:imptest>
> microbenchmark(fun1(), times=10000)
Unit: microseconds
   expr    min     lq median      uq     max neval
 fun1() 24.506 25.654 26.324 27.8795 154.001 10000
> microbenchmark(fun2(), times=10000)
Unit: microseconds
   expr    min      lq  median      uq     max neval
 fun2() 42.723 46.6945 48.8685 52.0595 2021.91 10000

Also, if one uses roxygen2 (or even if one doesn't) ##'@importFrom above
the function doing the calling documents this.

And of course if you need to know where a function lives environment will
tell you.

~G


On Fri, May 30, 2014 at 10:00 AM, Hadley Wickham <[hidden email]>
wrote:

> > There is at least one subtle consequence to keep in mind when doing
> > this. Of course, whatever choice you make, if the whatever() function
> > moves to a different package, this breaks your package.
> > However, if you explicitly import the function, your package will
> > break at load-time (which is good) and you'll only have to modify
> > 1 line in the NAMESPACE file to fix it. But if you do foo::whatever(),
> > your package won't break at load-time, only at run-time. Also you'll
> > have to edit all the calls to foo::whatever() to fix the package.
> >
> > Probably not a big deal, but in an environment like Bioconductor where
> > infrastructure classes and functions can be shared by hundreds of
> > packages, having people use foo::whatever() in a systematic way would
> > probably make maintenance a little bit more painful than it needs to
> > be when the need arises to reorganize/refactor parts of the
> > infrastructure. Also, the ability to quickly grep the NAMESPACE
> > files of all BioC packages to see who imports what is very convenient
> > in this situation.
>
> OTOH, I think there's a big benefit to being able to read package code
> and instantly know where a function comes from.
>
> Personally, I found this outweighs the benefits that you outline:
>
> * functions rarely move between packages, and gsubbing for pkga:foo to
> pkgb:foo isn't hard
> * it's not that much hard to grep for pkg::foo in R/* than it is to
> grep NAMESPACE
>
> Hadley
>
> --
> http://had.co.nz/
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

Gábor Csárdi
In reply to this post by Hervé Pagès
On Fri, May 30, 2014 at 6:55 PM, Hervé Pagès <[hidden email]> wrote:
[...]

> There is at least one subtle consequence to keep in mind when doing
> this. Of course, whatever choice you make, if the whatever() function
> moves to a different package, this breaks your package.
> However, if you explicitly import the function, your package will
> break at load-time (which is good) and you'll only have to modify
> 1 line in the NAMESPACE file to fix it. But if you do foo::whatever(),
> your package won't break at load-time, only at run-time. Also you'll
> have to edit all the calls to foo::whatever() to fix the package.
>

It'll break at run-time, yes, but if you use pkg::fun and fun is not in pkg
any more, then AFAIK you'll get a warning from R CMD check.

Gabor

[...]

        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

Hervé Pagès
In reply to this post by hadley wickham
On 05/30/2014 10:00 AM, Hadley Wickham wrote:

>> There is at least one subtle consequence to keep in mind when doing
>> this. Of course, whatever choice you make, if the whatever() function
>> moves to a different package, this breaks your package.
>> However, if you explicitly import the function, your package will
>> break at load-time (which is good) and you'll only have to modify
>> 1 line in the NAMESPACE file to fix it. But if you do foo::whatever(),
>> your package won't break at load-time, only at run-time. Also you'll
>> have to edit all the calls to foo::whatever() to fix the package.
>>
>> Probably not a big deal, but in an environment like Bioconductor where
>> infrastructure classes and functions can be shared by hundreds of
>> packages, having people use foo::whatever() in a systematic way would
>> probably make maintenance a little bit more painful than it needs to
>> be when the need arises to reorganize/refactor parts of the
>> infrastructure. Also, the ability to quickly grep the NAMESPACE
>> files of all BioC packages to see who imports what is very convenient
>> in this situation.
>
> OTOH, I think there's a big benefit to being able to read package code
> and instantly know where a function comes from.

To me this is way more readable:

   setClass("A", representation(...))
   setMethod("head", "A", function(x, ...) {...})

than this:

   methods::setClass("A", methods::representation(...))
   methods::setMethod(utils::head, "A", function(x, ...) {...})

All the :: clutter adds very little value and hurts readability.
Just a matter of taste I guess.

Also it almost never matters to me *where* a function comes from.
The only thing I find relevant when I read code is *what* a function
does and I can find out by doing ?whatever (I generally don't need
to do ?foo::whatever). If I need to try it (interactively), I do
whatever(...), not foo::whatever(...). Sometimes, ?whatever will
fail because foo's NAMESPACE is loaded but foo is not attached to my
search path. In that case, and in that case only, I need to know
*where* the function comes from so I can library() the package where
it's defined and documented, and then I can do ?whatever. But this is
a rare situation and doesn't justify systematic use of foo::whatever().

So I only reserve the use of foo::whatever() to disambiguate in case
of name collision or to call a function defined in a *suggested*
package.

Finally, now that the use of a NAMESPACE became mandatory (well, this
happened a few years ago), advocating systematic use of foo::whatever()
without explicitly importing the function sounds a little bit like an
heroic act of resistance ;-)

H.

>
> Personally, I found this outweighs the benefits that you outline:
>
> * functions rarely move between packages, and gsubbing for pkga:foo to
> pkgb:foo isn't hard
> * it's not that much hard to grep for pkg::foo in R/* than it is to
> grep NAMESPACE
>
> Hadley
>

--
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: [hidden email]
Phone:  (206) 667-5791
Fax:    (206) 667-1319

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

hadley wickham
> Finally, now that the use of a NAMESPACE became mandatory (well, this
> happened a few years ago), advocating systematic use of foo::whatever()
> without explicitly importing the function sounds a little bit like an
> heroic act of resistance ;-)

I don't think that's at all true - for most other programming
languages, the preferred style is to explicitly refer to functions,
including their namespace/package etc.

Hadley

--
http://had.co.nz/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

Gábor Csárdi
On Fri, May 30, 2014 at 9:08 PM, Hadley Wickham <[hidden email]> wrote:

> > Finally, now that the use of a NAMESPACE became mandatory (well, this
> > happened a few years ago), advocating systematic use of foo::whatever()
> > without explicitly importing the function sounds a little bit like an
> > heroic act of resistance ;-)
>
> I don't think that's at all true - for most other programming
> languages, the preferred style is to explicitly refer to functions,
> including their namespace/package etc.
>

I think with R the issue of having functions with the same name (but
different semantics) imported from different packages does not come up too
often. IMHO the reason for this is (partly) historical. In the past there
were no namespaces, at least they were not mandatory, and packages were
loaded and attached as a whole, so people were defensive and used very
specific function names to avoid name clashes.

I chose graph.density() over density() and chose graph.adjlist() over
adjlist(), etc. Last week I am chose diff() over git_diff(), and I guess I
am not the only one with this tendency. It is just a matter of time to have
a bunch of packages with a diff() function, and then it will matter where
diff() is coming from.

Gabor


>
> Hadley
>
> --
> http://had.co.nz/
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

Gábor Csárdi
On Fri, May 30, 2014 at 9:17 PM, Gábor Csárdi <[hidden email]>
wrote:

> On Fri, May 30, 2014 at 9:08 PM, Hadley Wickham <[hidden email]>
> wrote:
>
>> > Finally, now that the use of a NAMESPACE became mandatory (well, this
>> > happened a few years ago), advocating systematic use of foo::whatever()
>> > without explicitly importing the function sounds a little bit like an
>> > heroic act of resistance ;-)
>>
>> I don't think that's at all true - for most other programming
>> languages, the preferred style is to explicitly refer to functions,
>> including their namespace/package etc.
>>
>
> I think with R the issue of having functions with the same name (but
> different semantics) imported from different packages does not come up too
> often. IMHO the reason for this is (partly) historical. In the past there
> were no namespaces, at least they were not mandatory, and packages were
> loaded and attached as a whole, so people were defensive and used very
> specific function names to avoid name clashes.
>
> I chose graph.density() over density() and chose graph.adjlist() over
> adjlist(), etc. Last week I am chose diff() over git_diff(), and I guess I
> am not the only one with this tendency. It is just a matter of time to have
> a bunch of packages with a diff() function, and then it will matter where
> diff() is coming from.
>
Btw. this said, personally I still prefer importFrom(pkg, diff) and then
diff() to pkg::diff(), most of the time.

Gabor

[...]

        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

Hervé Pagès
In reply to this post by Gabriel Becker
Hi Gabe,

On 05/30/2014 11:34 AM, Gabriel Becker wrote:

> This isn't likely to make much difference in most cases, but calling a
> function via :: can incur up to about twice the overhead on average
> compared to calling an imported function
>
>  > fun1
> function ()
> file_ext("text.txt")
> <environment: namespace:imptest>
>  > fun2
> function ()
> tools::file_ext("text.txt")
> <environment: namespace:imptest>
>  > microbenchmark(fun1(), times=10000)
> Unit: microseconds
>     expr    min     lq median      uq     max neval
>   fun1() 24.506 25.654 26.324 27.8795 154.001 10000
>  > microbenchmark(fun2(), times=10000)
> Unit: microseconds
>     expr    min      lq  median      uq     max neval
>   fun2() 42.723 46.6945 48.8685 52.0595 2021.91 10000

Interesting. Or with a void function so the timing more closely
reflects the time it takes to look up the symbol:

   > void
   function ()
   NULL
   <environment: namespace:S4Vectors>

   > fun1
   function ()
   void()
   <environment: namespace:IRanges>

   > fun2
   function ()
   S4Vectors::void()
   <environment: namespace:IRanges>

   > microbenchmark(fun1(), times=10000)
   Unit: nanoseconds
      expr min  lq median  uq   max neval
    fun1() 261 268    270 301 11960 10000
   > microbenchmark(fun2(), times=10000)
   Unit: microseconds
      expr    min     lq median     uq      max neval
    fun2() 13.486 14.918 15.782 16.753 60542.19 10000

S4Vectors::void() is about 60x slower than void()!

Cheers,
H.

>
> Also, if one uses roxygen2 (or even if one doesn't) ##'@importFrom above
> the function doing the calling documents this.
>
> And of course if you need to know where a function lives environment
> will tell you.
>
> ~G
>
>
> On Fri, May 30, 2014 at 10:00 AM, Hadley Wickham <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>      > There is at least one subtle consequence to keep in mind when doing
>      > this. Of course, whatever choice you make, if the whatever() function
>      > moves to a different package, this breaks your package.
>      > However, if you explicitly import the function, your package will
>      > break at load-time (which is good) and you'll only have to modify
>      > 1 line in the NAMESPACE file to fix it. But if you do
>     foo::whatever(),
>      > your package won't break at load-time, only at run-time. Also you'll
>      > have to edit all the calls to foo::whatever() to fix the package.
>      >
>      > Probably not a big deal, but in an environment like Bioconductor
>     where
>      > infrastructure classes and functions can be shared by hundreds of
>      > packages, having people use foo::whatever() in a systematic way would
>      > probably make maintenance a little bit more painful than it needs to
>      > be when the need arises to reorganize/refactor parts of the
>      > infrastructure. Also, the ability to quickly grep the NAMESPACE
>      > files of all BioC packages to see who imports what is very convenient
>      > in this situation.
>
>     OTOH, I think there's a big benefit to being able to read package code
>     and instantly know where a function comes from.
>
>     Personally, I found this outweighs the benefits that you outline:
>
>     * functions rarely move between packages, and gsubbing for pkga:foo to
>     pkgb:foo isn't hard
>     * it's not that much hard to grep for pkg::foo in R/* than it is to
>     grep NAMESPACE
>
>     Hadley
>
>     --
>     http://had.co.nz/
>
>     ______________________________________________
>     [hidden email] <mailto:[hidden email]> mailing list
>     https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis

--
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: [hidden email]
Phone:  (206) 667-5791
Fax:    (206) 667-1319

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Style question

Winston Chang
Using `::` does add some overhead - on the order of 5-10 microseconds
on my computer. Still, it would take 100,000 calls to add 0.5-1 second
of delay.

microbenchmark(
  base::identity(1),
  identity(1),
  unit = "us"
)
# Unit: microseconds
#               expr   min     lq median     uq    max neval
#  base::identity(1) 5.677 6.2180 6.6695 7.3655 60.104   100
#        identity(1) 0.262 0.2965 0.3210 0.4035  1.034   100

This test isn't exactly like putting identity in imports, since in
this case, the number environments to search is greater -- but it's
reasonably close.

If you're in a situation where you want to be explicit about where a
function came from, but the slowness of `::` is an issue, you could
create a variable that points to the environment and access the
function using $:

base <- as.environment('package:base')
microbenchmark(
  base::identity(1),
  base$identity(1),
  identity(1),
  unit = "us"
)
# Unit: microseconds
#               expr   min     lq median     uq    max neval
#  base::identity(1) 5.520 6.0795 6.4485 7.0020 32.232   100
#   base$identity(1) 0.504 0.5940 0.6635 0.8105  7.701   100
#        identity(1) 0.248 0.2815 0.3100 0.3885  7.925   100


-Winston

On Fri, May 30, 2014 at 2:53 PM, Hervé Pagès <[hidden email]> wrote:

> Hi Gabe,
>
>
> On 05/30/2014 11:34 AM, Gabriel Becker wrote:
>>
>> This isn't likely to make much difference in most cases, but calling a
>> function via :: can incur up to about twice the overhead on average
>> compared to calling an imported function
>>
>>  > fun1
>> function ()
>> file_ext("text.txt")
>> <environment: namespace:imptest>
>>  > fun2
>> function ()
>> tools::file_ext("text.txt")
>> <environment: namespace:imptest>
>>  > microbenchmark(fun1(), times=10000)
>> Unit: microseconds
>>     expr    min     lq median      uq     max neval
>>   fun1() 24.506 25.654 26.324 27.8795 154.001 10000
>>  > microbenchmark(fun2(), times=10000)
>> Unit: microseconds
>>     expr    min      lq  median      uq     max neval
>>   fun2() 42.723 46.6945 48.8685 52.0595 2021.91 10000
>
>
> Interesting. Or with a void function so the timing more closely
> reflects the time it takes to look up the symbol:
>
>   > void
>   function ()
>   NULL
>   <environment: namespace:S4Vectors>
>
>   > fun1
>   function ()
>   void()
>   <environment: namespace:IRanges>
>
>   > fun2
>   function ()
>   S4Vectors::void()
>   <environment: namespace:IRanges>
>
>   > microbenchmark(fun1(), times=10000)
>   Unit: nanoseconds
>
>      expr min  lq median  uq   max neval
>    fun1() 261 268    270 301 11960 10000
>
>   > microbenchmark(fun2(), times=10000)
>   Unit: microseconds
>      expr    min     lq median     uq      max neval
>    fun2() 13.486 14.918 15.782 16.753 60542.19 10000
>
> S4Vectors::void() is about 60x slower than void()!
>
> Cheers,
> H.
>
>>
>> Also, if one uses roxygen2 (or even if one doesn't) ##'@importFrom above
>> the function doing the calling documents this.
>>
>> And of course if you need to know where a function lives environment
>> will tell you.
>>
>> ~G
>>
>>
>> On Fri, May 30, 2014 at 10:00 AM, Hadley Wickham <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>      > There is at least one subtle consequence to keep in mind when doing
>>      > this. Of course, whatever choice you make, if the whatever()
>> function
>>      > moves to a different package, this breaks your package.
>>      > However, if you explicitly import the function, your package will
>>      > break at load-time (which is good) and you'll only have to modify
>>      > 1 line in the NAMESPACE file to fix it. But if you do
>>     foo::whatever(),
>>      > your package won't break at load-time, only at run-time. Also
>> you'll
>>      > have to edit all the calls to foo::whatever() to fix the package.
>>      >
>>      > Probably not a big deal, but in an environment like Bioconductor
>>     where
>>      > infrastructure classes and functions can be shared by hundreds of
>>      > packages, having people use foo::whatever() in a systematic way
>> would
>>      > probably make maintenance a little bit more painful than it needs
>> to
>>      > be when the need arises to reorganize/refactor parts of the
>>      > infrastructure. Also, the ability to quickly grep the NAMESPACE
>>      > files of all BioC packages to see who imports what is very
>> convenient
>>      > in this situation.
>>
>>     OTOH, I think there's a big benefit to being able to read package code
>>     and instantly know where a function comes from.
>>
>>     Personally, I found this outweighs the benefits that you outline:
>>
>>     * functions rarely move between packages, and gsubbing for pkga:foo to
>>     pkgb:foo isn't hard
>>     * it's not that much hard to grep for pkg::foo in R/* than it is to
>>     grep NAMESPACE
>>
>>     Hadley
>>
>>     --
>>     http://had.co.nz/
>>
>>     ______________________________________________
>>     [hidden email] <mailto:[hidden email]> mailing list
>>
>>     https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>>
>> --
>> Gabriel Becker
>> Graduate Student
>> Statistics Department
>> University of California, Davis
>
>
> --
> 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: [hidden email]
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel