[Rd] Identical copy of base function
Hello, Regarding this in R-devel/NEWS/New features : o library(pkg) no longer warns about a conflict with a function from package:base if the function is an identical copy of the base one but with a different environment. Why would one want an identical copy in a different environment? I'm thinking I may be missing out on a trick here. Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
> Matthew Dowle > on Mon, 27 Feb 2012 09:59:43 + writes: > Hello, > Regarding this in R-devel/NEWS/New features : > o 'library(pkg)' no longer warns about a conflict with a > function from 'package:base' if the function is an > identical copy of the base one but with a different > environment. > Why would one want an identical copy in a different > environment? I'm thinking I may be missing out on a trick > here. Yes, you are ;-) The trick is called ``namespace'' : One example which lead me to implement the above: The Matrix package has had an identical copy of 'det' for a while now, but of course in the Matrix namespace. Because of that, the call to determinant() inside det() will correctly dispatch Matrix methods for determinant(), whereas base::det() would not. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
Doesn't this also mean that if Matrix is loaded first, det() will be calling Matrix::determinant, which could be quite surprising change in behavior from expectation? This seems rather dangerous and 'untrustworthy' to me - unless I am missing some other hidden mechanism involved here. I haven't read the code yet, and I am sure Matrix will "do the right thing", but I have strong reservations about this behavior when applied to the general universe of R and CRAN. Jeff On Mon, Feb 27, 2012 at 6:03 AM, Martin Maechler wrote: >> Matthew Dowle >> on Mon, 27 Feb 2012 09:59:43 + writes: > > > Hello, > > > Regarding this in R-devel/NEWS/New features : > > > o 'library(pkg)' no longer warns about a conflict with a > > function from 'package:base' if the function is an > > identical copy of the base one but with a different > > environment. > > > Why would one want an identical copy in a different > > environment? I'm thinking I may be missing out on a trick > > here. > > Yes, you are ;-) The trick is called ``namespace'' : > > One example which lead me to implement the above: > > The Matrix package has had an identical copy of 'det' for a > while now, but of course in the Matrix namespace. > Because of that, the call to determinant() inside det() will > correctly dispatch Matrix methods for determinant(), whereas > base::det() would not. > > Martin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com R/Finance 2012: Applied Finance with R www.RinFinance.com See you in Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
> Jeffrey Ryan
> on Mon, 27 Feb 2012 07:39:32 -0600 writes:
> Doesn't this also mean that if Matrix is loaded first,
> det() will be calling Matrix::determinant, which could be
> quite surprising change in behavior from expectation?
> This seems rather dangerous and 'untrustworthy' to me -
> unless I am missing some other hidden mechanism involved here.
The only change in R-devel is that library() does not warn about
*conflicts* in such a case.
This behavior (and the R code in library()'s checkConflicts())
is completely analogous to
importFrom("base", det)
export(det)
but as you surely know, we can not (yet?) import from base.
So again: No changed behavior of R, just some warnings less in a
case where they are typically inappropriate.
> I haven't read the code yet, and I am sure Matrix will "do
> the right thing", but I have strong reservations about
> this behavior when applied to the general universe of R
> and CRAN.
> Jeff
> On Mon, Feb 27, 2012 at 6:03 AM, Martin Maechler
> wrote:
>>> Matthew Dowle on Mon,
>>> 27 Feb 2012 09:59:43 + writes:
>>
>> > Hello,
>>
>> > Regarding this in R-devel/NEWS/New features :
>>
>> > o 'library(pkg)' no longer warns about a conflict
>> with a > function from 'package:base' if the function
>> is an > identical copy of the base one but with a
>> different > environment.
>>
>> > Why would one want an identical copy in a different
>> > environment? I'm thinking I may be missing out on a
>> trick > here.
>>
>> Yes, you are ;-) The trick is called ``namespace'' :
>>
>> One example which lead me to implement the above:
>>
>> The Matrix package has had an identical copy of 'det' for
>> a while now, but of course in the Matrix namespace.
>> Because of that, the call to determinant() inside det()
>> will correctly dispatch Matrix methods for determinant(),
>> whereas base::det() would not.
>>
>> Martin
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> --
> Jeffrey Ryan jeffrey.r...@lemnica.com
> www.lemnica.com www.esotericR.com
> R/Finance 2012: Applied Finance with R www.RinFinance.com
> See you in Chicago
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
On Mon, Feb 27, 2012 at 9:19 AM, Martin Maechler
wrote:
>> Jeffrey Ryan
>> on Mon, 27 Feb 2012 07:39:32 -0600 writes:
>
> > Doesn't this also mean that if Matrix is loaded first,
> > det() will be calling Matrix::determinant, which could be
> > quite surprising change in behavior from expectation?
>
>
> > This seems rather dangerous and 'untrustworthy' to me -
> > unless I am missing some other hidden mechanism involved here.
>
> The only change in R-devel is that library() does not warn about
> *conflicts* in such a case.
Yes, I understand that is only the warning here - but what, aside from
hiding a conflict (which the user may *indeed* care about), does this
accomplish?
To me, a conflict is something to be aware of - hiding it is where I
become concerned.
Without warning, one R script may run differently now depending on
packages loaded, and not just package functions explicitly called by
the script. Without the warning I can envision countless hours
attempting to debug errors - if one is lucky enough to note the change
in behavior.
Behavioral changes can also related to performance. I had seen this
previously with some cbind behavior when the S4 variant from
package:methods overwrote the (much faster) base::cbind by a package
which I will not name (and has since been fixed).
Jeff
> This behavior (and the R code in library()'s checkConflicts())
> is completely analogous to
> importFrom("base", det)
> export(det)
> but as you surely know, we can not (yet?) import from base.
>
> So again: No changed behavior of R, just some warnings less in a
> case where they are typically inappropriate.
>
> > I haven't read the code yet, and I am sure Matrix will "do
> > the right thing", but I have strong reservations about
> > this behavior when applied to the general universe of R
> > and CRAN.
>
> > Jeff
>
> > On Mon, Feb 27, 2012 at 6:03 AM, Martin Maechler
> > wrote:
> >>> Matthew Dowle on Mon,
> >>> 27 Feb 2012 09:59:43 + writes:
> >>
> >> > Hello,
> >>
> >> > Regarding this in R-devel/NEWS/New features :
> >>
> >> > o 'library(pkg)' no longer warns about a conflict
> >> with a > function from 'package:base' if the function
> >> is an > identical copy of the base one but with a
> >> different > environment.
> >>
> >> > Why would one want an identical copy in a different
> >> > environment? I'm thinking I may be missing out on a
> >> trick > here.
> >>
> >> Yes, you are ;-) The trick is called ``namespace'' :
> >>
> >> One example which lead me to implement the above:
> >>
> >> The Matrix package has had an identical copy of 'det' for
> >> a while now, but of course in the Matrix namespace.
> >> Because of that, the call to determinant() inside det()
> >> will correctly dispatch Matrix methods for determinant(),
> >> whereas base::det() would not.
> >>
> >> Martin
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> > --
> > Jeffrey Ryan jeffrey.r...@lemnica.com
>
> > www.lemnica.com www.esotericR.com
>
> > R/Finance 2012: Applied Finance with R www.RinFinance.com
>
> > See you in Chicago
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
R/Finance 2012: Applied Finance with R
www.RinFinance.com
See you in Chicago
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
