(Comment near the bottom of the text.)
Seth Falcon wrote:
> * On 2008-06-01 at 11:30 -0400 John Chambers wrote:
>
>> My impression (but just as a user, not an implementer) is that the
>> NAMESPACE mechanism is intended to search for anything, not just for
>> methods, as follows:
>>
>> - look in the namespace itself;
>> - look in the imports, which are in the parent.env of the namespace;
>> - look in the base package's namespace.
>>
>
> As described in the R News article [1], the above describes the static
> component of the search mechanism, but there is a dynamic component
> which adds:
>
> - look in .GlobalEnv
> - look in each package on the search path
> - look (again) in base
>
> [1] http://cran.r-project.org/doc/Rnews/Rnews_2003-1.pdf
>
>
>> Period. This provides a definition of the behavior of functions in the
>> package that is independent of the dynamically changing contents of the
>> search list.
>>
>
> I think the dynamic lookup is important. Consider class Foo and some
> methods, like show, for working with Foo instances defined in pkgA.
> Further, suppose pkgB imports pkgA and contains a function that
> returns a Foo instance.
>
> If a user class library("pkgB") at the prompt, both the developer and
> the user would like for methods for dealing with Foo instances to be
> available.
>
> This has been achieved by adding pkgA to the Depends field of pkgB.
> In this case, library("pkgB") has the side-effect of attaching pkgA to
> the search path and Foo instances behave as desired. This, I believe,
> describes the first part of Martin's example:
>
> Martin Morgan:
>
>>>> library(KEGG.db) # Imports, Depends AnnotationDbi; KEGG.db is data-only
>>>> head(ls(KEGGPATHID2EXTID))
>>>>
>>>>
>>> [1] "hsa00232" "hsa00230" "hsa04514" "hsa04010" "hsa04012" "hsa04150"
>>>
>>>
>
> John Chambers:
>
>> "Depends" may cause the relevant packages to be put on the search list.
>> But a subsequent attach or detach could change what objects were found.
>> So unless this is not the intended interpretation of namespaces, looking
>> in the search list seems a bad idea in principle.
>>
>
> I agree that using the dynamic lookup when the static lookup is
> available is bad programming practice. However, given the flexibility
> of the current tools, it seems not unreasonable to expect that
> picking up a method via the search path would work in a package just
> as it does (should?) interactively.
>
Well, I'm not against that, if it coincides with the general view of
namespaces.
However, it's not required for the methods to be available, AFAICS.
For example, "show" is a generic function associated with the "methods"
package. When a package is loaded with methods for "show", those
methods are merged into the methods table for that generic function.
Any calls to that generic function, from whatever other package, see the
consistent version of the generic, and therefore the new methods.
(That's a description specifically from the r-devel version. If there's
evidence to the contrary, it would likely be a bug.)
The error in Martin's example is in evaluating an argument. Without
more detail, I don't see what that has to do with method selection per se.
John
>
> + seth
>
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
