From seth at userprimary.net  Mon Mar 22 17:36:14 2010
From: seth at userprimary.net (Seth Falcon)
Date: Mon, 22 Mar 2010 09:36:14 -0700
Subject: [Rd] Suggestion: Not having to export .conflicts.OK in name
	spaces
In-Reply-To: <19367.19767.308713.426235@lynne.math.ethz.ch>
References: <59d7961d1003170911o38814b59h3fdb4de42e21b723@mail.gmail.com>	<4BA3E2D5.5050305@userprimary.net>
	<19367.19767.308713.426235@lynne.math.ethz.ch>
Message-ID: <4BA79C7E.3040701@userprimary.net>

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.

>
>      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

+ seth

-- 
Seth Falcon | @sfalcon | http://userprimary.net/



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