[Rd] Suggestion: Not having to export .conflicts.OK in name spaces

[Henrik Bengtsson]

Hi.

On Mon, Mar 22, 2010 at 5:36 PM, Seth Falcon <seth at userprimary.net> wrote:
> On 3/22/10 3:57 AM, Martin Maechler wrote:
>>>>>>>
>>>>>>> "SF" == Seth Falcon<seth at userprimary.net>
>>>>>>>     on Fri, 19 Mar 2010 13:47:17 -0700 writes:
>>
>>     SF>  On 3/17/10 9:11 AM, Henrik Bengtsson wrote:
>>     >>  Currently library() and attach() fail to locate an
>>     >>  existing '.conflicts.OK' in a package wit name space,
>>     >>  unless it is exported.  Since there should be little
>>     >>  interest in exporting '.conflicts.OK' otherwise, one may
>>     >>  argue that those methods should look for '.conflicts.OK'
>>     >>  even if it is not exported.
>>
>>     SF>  I guess I agree that there is no real value in forcing
>>     SF>  .conflicts.OK to be exported.
>> so do I.
>
> So I guess we agree that Henrik's patch would be worth applying.
>
> @Henrik: if you resend your patch with the additions for attach, I will see
> about putting it in.

When looking more carefully at base::attach(), I see that there is
nothing to do, because attach() takes a data.frame, a list, an
environment, NULL, or a file saved using base::save().  None of these
can have a name space.

The scenario I was "worrying about" was when you attach() the
environment of a package with a namespace, e.g.

envir <- as.environment("package:graphics");
envir2 <- attach(envir, name="foo");
ls(envir=envir2, all.names=TRUE);

but to the best of my understanding it is only exported objects that
are attached, i.e. if .conflicts.OK is not exported by the package,
then it won't be attached and hence not exist either way.  Is that
correct?

envir <- as.environment("package:R.utils");
envir2 <- attach(envir, name="foo");
ls(envir=envir2, all.names=TRUE);

>
>>
>>     SF>  OTOH, this seems like a dubious feature to begin.  When
>>     SF>  is it a good idea to use it?
>>
>> in cases, the package author thinks (s)he knows what (s)he is
>> doing;
>> e.g. in the case of Matrix, I could argue that I know about the
>> current conflicts, and I would *not* want the users of my
>> package be intimidated by warnings about maskings...
>
> I can't say that this convinces me that .conflicts.OK is OK.  Are there
> package authors who realize they do not know what they are doing enough to
> keep the warning messages :-P

I define throw.default() in R.methodsS3:

> R.methodsS3::throw.default
function (...)
{
    stop(...)
}
<environment: namespace:R.methodsS3>

In R.oo, which loads R.methodsS3, I override this with:

> R.oo::throw.default
function (...)
{
    throw(Exception(...))
}
<environment: namespace:R.oo>

The Exception class is defined in R.oo.  If someone loads R.methodsS3
alone, you get a throw() method.  Someone loading R.oo will get the a
throw() that is backward compatible but with some extra bells and
whistles recording the strack trace etc.  This is an intended design.

So when I load R.oo, I don't want the warning of overloading throw()
in R.methodsS3.  Is there an alternative for me?

Ideally, there should be a way to specify which objects are "ok",
instead of all or none.

Thanks

Henrik

>
> + seth
>
> --
> Seth Falcon | @sfalcon | http://userprimary.net/
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>