Hi. On Mon, Mar 22, 2010 at 5:36 PM, Seth Falcon <s...@userprimary.net> wrote: > On 3/22/10 3:57 AM, Martin Maechler wrote: >>>>>>> >>>>>>> "SF" == Seth Falcon<s...@userprimary.net> >>>>>>> on Fri, 19 Mar 2010 13:47:17 -0700 writes: >> >> SF> On 3/17/10 9:11 AM, Henrik Bengtsson wrote: >> >> Currently library() and attach() fail to locate an >> >> existing '.conflicts.OK' in a package wit name space, >> >> unless it is exported. Since there should be little >> >> interest in exporting '.conflicts.OK' otherwise, one may >> >> argue that those methods should look for '.conflicts.OK' >> >> even if it is not exported. >> >> SF> I guess I agree that there is no real value in forcing >> SF> .conflicts.OK to be exported. >> so do I. > > So I guess we agree that Henrik's patch would be worth applying. > > @Henrik: if you resend your patch with the additions for attach, I will see > about putting it in.
When looking more carefully at base::attach(), I see that there is nothing to do, because attach() takes a data.frame, a list, an environment, NULL, or a file saved using base::save(). None of these can have a name space. The scenario I was "worrying about" was when you attach() the environment of a package with a namespace, e.g. envir <- as.environment("package:graphics"); envir2 <- attach(envir, name="foo"); ls(envir=envir2, all.names=TRUE); but to the best of my understanding it is only exported objects that are attached, i.e. if .conflicts.OK is not exported by the package, then it won't be attached and hence not exist either way. Is that correct? envir <- as.environment("package:R.utils"); envir2 <- attach(envir, name="foo"); ls(envir=envir2, all.names=TRUE); > >> >> SF> OTOH, this seems like a dubious feature to begin. When >> SF> is it a good idea to use it? >> >> in cases, the package author thinks (s)he knows what (s)he is >> doing; >> e.g. in the case of Matrix, I could argue that I know about the >> current conflicts, and I would *not* want the users of my >> package be intimidated by warnings about maskings... > > I can't say that this convinces me that .conflicts.OK is OK. Are there > package authors who realize they do not know what they are doing enough to > keep the warning messages :-P I define throw.default() in R.methodsS3: > R.methodsS3::throw.default function (...) { stop(...) } <environment: namespace:R.methodsS3> In R.oo, which loads R.methodsS3, I override this with: > R.oo::throw.default function (...) { throw(Exception(...)) } <environment: namespace:R.oo> The Exception class is defined in R.oo. If someone loads R.methodsS3 alone, you get a throw() method. Someone loading R.oo will get the a throw() that is backward compatible but with some extra bells and whistles recording the strack trace etc. This is an intended design. So when I load R.oo, I don't want the warning of overloading throw() in R.methodsS3. Is there an alternative for me? Ideally, there should be a way to specify which objects are "ok", instead of all or none. Thanks Henrik > > + seth > > -- > Seth Falcon | @sfalcon | http://userprimary.net/ > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel