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 <ggrothendieck@gmail.com
> wrote:

> On Thu, Aug 22, 2013 at 6:41 PM, Uwe Ligges
> <ligges@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 <
> ggrothendieck@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]]

