Hi,

I encounter similar problems as well and posted a while ago about this. 
Namespaces are cool, but isn't it very much up to a package's position 
in the search path (which is quite arbitrary depending on the packages 
loaded) that determines which namespace "dominates"? That leaves it to 
the user to figure out when it's safe to simply hit 'foo()' or when 
he/she has to get more specific with 'thePackage::foo()' in order to 
make sure the desired function is called.

I'm guessing that the reason for this (amongst others) are that
a) there are some good reasons to stick to this (e.g. someone pointed 
out, that using the pointer '::' is less efficient compared to assigning 
'thePackage::foo()' to an actual object and use this instead; plus 
'thePackage::foo()' is somewhat verbose and you would need to get used 
to knowing what package a function belongs to; plenty more reasons that 
I don't know of ;-))
b) it's not easily possible to change anything about this as this is 
pretty fundamental stuff

Yet, IMHO there will be more and more problems regarding this in the 
future as the number of contributed packages keeps growing. I personally 
would not mind at all to get used to typing 'thePackage::foo()' *all* 
the time, or at least have this as an option. In principal, this is no 
big deal once you actually *have* a true package with a namespace at 
hand. But what about the process of creating a package? AFAU, there is 
no way of "simulating/emulating" a namespace (which I understand is some 
special form of environment?) in order to be able to use '::' when 
creating/debugging functions that call other functions of the unfinished 
package. If anyone has some ideas on that one, I would appreciate to hear.

Best regards,
Janko

On 20.05.2011 09:28, Rolf Turner wrote:
>
> My understanding (which is pretty shaky when it comes to namespaces) is
> that if you have things set up correctly then namespaces will make sure
> that function calls within functions in the given package will be to 
> be to
> functions in that package and not to their doppelgangers in other 
> packages
> which may be attached.
>
> E.g. if you have another function in the "teaser" package that calls 
> lm(),
> (and if you have the teaser namespace set up properly) it will call the
> lm() in the teaser package and *not* the lm() in the "stats" package.
>
> But a call to lm() from a function not in "teaser", or from the command
> line will get the lm() in whichever package ("teaser" or "stats") is 
> closer
> to the start of the search path.  And there's really nothing much that
> can be done about this.  Have I got that right?
>
>     cheers,
>
>             Rolf Turner
> On 20/05/11 18:26, Jari Oksanen wrote:
>> Duncan Murdoch<murdoch.duncan<at>  gmail.com>  writes:
>>
>>> On 18/05/2011 10:02 PM, Nick Matzke wrote:
>>>> Hi,
>>>>
>>>> If I load 2 packages that have a function with the same
>>>> name, how do I tell R to run one or the other?
>>>>
>>> If you are using a package without a namespace, expect problems.  
>>> Having
>>> the namespace is nearly as good as automatically adding the pkg:: 
>>> prefix
>>> to every call from functions within the package.  Not having the
>>> namespace is nearly as bad as never using the prefix, even when you 
>>> should.
>>>
>> I fail to see how namespace could help here. If you have identical 
>> function
>> names in two packages, one will still mask another and you'll need an 
>> explicit
>> pointer (::) to tell R which one to use. Here is an example:
>>
>>> lm(y ~ x)
>> Error in lm(y ~ x) : got you!
>>> lm
>> function (x, ...)
>> stop("got you!")
>> <environment: namespace:teaser>
>>
>> So there is an unreleased (fortunately!) package called "teaser"
>> which has only function called lm() that seems to do nothing useful, but
>> it masks the more useful function lm() in package "stats".  Both 
>> packages
>> ("teaser" and "stats") have namespace, but it didn't help here.
>>
>> Namespace may be useful when you got stray objects from two different
>> packages, and these should be handled by their dedicated support 
>> functions,
>> but I fail to see how namespace could help in resolving which of the 
>> two exported
>> functions to use at the top level.
>>
>> I have honest intentions in this query since I know that the package 
>> that I
>> maintain has a function with the same name as another package that is 
>> often
>> used alternately with our package. My resolution was to write a 
>> function that
>> detects the case and gives user a warning that the object they have was
>> created from that another package and cannot be adequately handled here.
>> However, it doesn't remove the confusion when people think they are 
>> using
>> one package but use another when doing the top level analysis.
>>
>> If there is a resolution to this, I'll be happy.
>>
>> Cheers, Jari Oksanen
>>
>> ______________________________________________
>> R-help@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide 
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>>
>
> ______________________________________________
> R-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>


-- 
------------------------------------------------------------------------

*Janko Thyson*
janko.thyson@ku-eichstaett.de <mailto:janko.thyson@ku-eichstaett.de>

Catholic University of Eichstätt-Ingolstadt
Ingolstadt School of Management
Statistics and Quantitative Methods
Auf der Schanz 49
D-85049 Ingolstadt

www.wfi.edu/lsqm <http://www.wfi.edu/lsqm>

Fon: +49 841 937-1923
Fax: +49 841 937-1965

This e-mail and any attachment is for authorized use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be
copied, disclosed to, retained or used by any other party.
If you are not an intended recipient then please promptly delete this
e-mail and any attachment and all copies and inform the sender.


-- 
------------------------------------------------------------------------

*Janko Thyson*
janko.thyson@googlemail.com <mailto:janko.thyson@googlemail.com>

Jesuitenstraße 3
D-85049 Ingolstadt

Mobile: +49 (0)176 83294257

This e-mail and any attachment is for authorized use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be
copied, disclosed to, retained or used by any other party.
If you are not an intended recipient then please promptly delete this
e-mail and any attachment and all copies and inform the sender.


	[[alternative HTML version deleted]]

