[Rd] legitimate use of :::

[Gabor Grothendieck]

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