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