My understanding is that lookup happens in the imports before moving on to the search path, so if I understand you correctly I don't think that is an issue. If A also *exported* f, that would be a problem...
>From writing R extensions (talking about functions in a package finding variables, sec 1.6): The namespace controls the search strategy for variables used by functions in the package. If not found locally, R searches the package namespace first, then the imports, then the base namespace and then the normal search path. On Thu, Aug 22, 2013 at 4:45 PM, Gabor Grothendieck <ggrothendi...@gmail.com > wrote: > On Thu, Aug 22, 2013 at 6:41 PM, Uwe Ligges > <lig...@statistik.tu-dortmund.de> wrote: > > > > > > On 23.08.2013 00:36, Brian Lee Yung Rowe wrote: > >> > >> You raise an interesting point that I've mulled over a bit: namespace > >> collisions. How many of these issues would go away if there were a > better > >> mechanism for managing namespaces? eg in other languages you can control > >> which objects/modules you wish to import from a library. Under this > regime I > >> think package developers would be less concerned about exposing > functions > >> that otherwise would be private. > > > > > > > > Exactly, the corresponding NAMESPACE directive is > > > > importFrom() > > > > and it should be used. > > > > > > > >> On Aug 22, 2013, at 6:27 PM, Gabor Grothendieck < > ggrothendi...@gmail.com> > >> wrote: > >> > >>> If ::: is disallowed then its likely that package developers will need > >>> to export more functions to satisfy the consumers of those otherwise > >>> hidden functions but if more functions are exported then there > >>> will be a greater likelihood of conflicts among packages. > >>> > >>> The problem seems to be that there are potentially three sorts of > >>> functions here: > >>> > >>> 1. a function is hidden > >>> 2. a function is accessible via ::: but is not on the search path > >>> 3. a function is on the search path > >> > >> > > > > Not entirely right: > > > > If the package or only parts of it are imported via importFrom by another > > package, the package is not loaded, hence not on the search path. > > OK but it is still true that under the new rules to use importFrom(B, > f) in package A > that f must be exported by B. That implies that f could cause a > conflict when B is > placed on the search path via library(B) by some other package > (package C) or by the user. > > f is either exported by B or not. If f is exported by B then f will > be placed on > the search path whenever B is placed on the search path and if f is > not exported then A can't import it. That is there is no way for B to > declare a function to be importable by another package without having that > function also placed on the search path whenever B is loaded by a > library(B)l or > a Depends: B from another package. > > > > > on the search path > > > -- > Statistics & Software Consulting > GKX Group, GKX Associates Inc. > tel: 1-877-GKX-GROUP > email: ggrothendieck at gmail.com > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
