Re: [Rd] NAMESPACE methods guidance, please
(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
Re: [Rd] NAMESPACE methods guidance, please
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.
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.
But the catch, it seems, is that the third element above, the base
namespace, has the Global namespace as its parent. As a result, I
believe the search continues through the entire search list, when one is
using exists() or get() in the ordinary way.
The effect is only noticeable, of course, if the object in question is
_not_ found in the first three environments searched. As a result, it's
not widely obvious. But it does seem, in principle, to violate the
concept of the namespace.
The mechanisms in the methods package that do searching are intended to
use the three-part interpretation of namespaces above; just what if
anything in the changes between 2.7.0 and r-devel would cause the
different results isn't obvious, but if I understand your example, the
current behavior seems as intended.
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.
Martin Morgan wrote:
My conception of how NAMESPACE and methods in R-2.7.0 resolved a
generic 'func' to a func-method was to search as follows:
In 2.7.0:
func --
NAMESPACE, including Imports: (and other details) --
.GlobalEnv, and eventually Depends: since these are on search()
In R-devel it seems like
func --
NAMESPACE, including Imports: (and other details) --
?? but not pkgs in Depends:
Is this correct or as intended, or is there a better conception to
have?
This model is from the following:
In 2.7.0:
library(KEGG.db) # Imports, Depends AnnotationDbi; KEGG.db is data-only
head(ls(KEGGPATHID2EXTID))
[1] hsa00232 hsa00230 hsa04514 hsa04010 hsa04012 hsa04150
vs. in a package tmpA with a NAMESPACE with Depend: and Imports:
KEGG.db and in a new session of R
library(tmpA)
dokegg
function ()
{
require(KEGG.db)
head(ls(KEGGPATHID2EXTID))
}
environment: namespace:tmpA
dokegg()
[1] hsa00232 hsa00230 hsa04514 hsa04010 hsa04012 hsa04150
In R-devel
dokegg()
Error in as.environment(pos) : invalid object for 'as.environment'
Error in head(ls(KEGGPATHID2EXTID)) :
error in evaluating the argument 'x' in selecting a method for function
'head'
In some ways this seems good (tmpA author has to specify use of
AnnotationDbi::ls, and tmpA is not confused by things the user does to
their environment) but in other ways it seems to undo any benefit of
method dispatch and requires the tmpA author to fully discover (and
monitor -- what if AnnotationDbi splits 'ls' into a AnnotationBase
pkg?) the class hierarchy.
The specific example of KEGG.db and AnnotationDbi is maybe more
interesting than others, because there is really no functionality to
be imported from KEGG.db.
Martin
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE methods guidance, please
* 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. + seth -- Seth Falcon | http://userprimary.net/user/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NAMESPACE methods guidance, please
My conception of how NAMESPACE and methods in R-2.7.0 resolved a
generic 'func' to a func-method was to search as follows:
In 2.7.0:
func --
NAMESPACE, including Imports: (and other details) --
.GlobalEnv, and eventually Depends: since these are on search()
In R-devel it seems like
func --
NAMESPACE, including Imports: (and other details) --
?? but not pkgs in Depends:
Is this correct or as intended, or is there a better conception to
have?
This model is from the following:
In 2.7.0:
library(KEGG.db) # Imports, Depends AnnotationDbi; KEGG.db is data-only
head(ls(KEGGPATHID2EXTID))
[1] hsa00232 hsa00230 hsa04514 hsa04010 hsa04012 hsa04150
vs. in a package tmpA with a NAMESPACE with Depend: and Imports:
KEGG.db and in a new session of R
library(tmpA)
dokegg
function ()
{
require(KEGG.db)
head(ls(KEGGPATHID2EXTID))
}
environment: namespace:tmpA
dokegg()
[1] hsa00232 hsa00230 hsa04514 hsa04010 hsa04012 hsa04150
In R-devel
dokegg()
Error in as.environment(pos) : invalid object for 'as.environment'
Error in head(ls(KEGGPATHID2EXTID)) :
error in evaluating the argument 'x' in selecting a method for function 'head'
In some ways this seems good (tmpA author has to specify use of
AnnotationDbi::ls, and tmpA is not confused by things the user does to
their environment) but in other ways it seems to undo any benefit of
method dispatch and requires the tmpA author to fully discover (and
monitor -- what if AnnotationDbi splits 'ls' into a AnnotationBase
pkg?) the class hierarchy.
The specific example of KEGG.db and AnnotationDbi is maybe more
interesting than others, because there is really no functionality to
be imported from KEGG.db.
Martin
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
