From ggrothendieck at gmail.com  Fri Aug 23 01:45:42 2013
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Thu, 22 Aug 2013 19:45:42 -0400
Subject: [Rd] legitimate use of :::
In-Reply-To: <521693A6.5030407@statistik.tu-dortmund.de>
References: <CANROs4dyoRyjoVHZLs7wDrFrjVX-1zvTTv2i4tBzF3f6Rx-XTA@mail.gmail.com>
	<5215F9BD.5030009@statistik.tu-dortmund.de> <52165F15.1090500@yorku.ca>
	<CABdHhvENvyTD6dPtbQzNaGqgwHNtV86juZh=5F7oBQSPJhO1Rw@mail.gmail.com>
	<BA069179-9E70-4CCE-BD8E-CCB01988B68E@muxspace.com>
	<CAP01uRnuo9kFwbDpmZrQhkF5Mo5EW5LZt623o6b7N7F804Rp0Q@mail.gmail.com>
	<ABEAF14C-9D05-4878-9A15-3FC9728C7951@muxspace.com>
	<521693A6.5030407@statistik.tu-dortmund.de>
Message-ID: <CAP01uR=OnxFTMDtzLdWbWF=kRtSaZ_Rt5FQDDtbBrEv518BocA@mail.gmail.com>

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



[Rd] legitimate use of :::
Gabor Grothendieck