"Laurent Gautier" <lgautier at gmail.com> writes:
2007/9/13, Seth Falcon <sfalcon at fhcrc.org>:
Hi Jim,
Martin Morgan <mtmorgan at fhcrc.org> writes:
John? Is that the original poster with drug problems?
It's inherited from further up the search path
library("hgu95av2.db")
library("hgu95av2")
exists("db_conn", as.environment("package:hgu95av2"))
exists("db_conn", as.environment("package:hgu95av2"), inherits=FALSE)
Yes that is exactly the problem. I've committed a quick fix to
annaffy so that inherits=FALSE is used. This helper function should
move to AnnotationDbi so there is one place that has a
are-you-a-db-package helper function.
This is probably a general issue when multiple packages with
near-identical variables can be loaded.
Well, only sort of. The real issue was my goof in not using exists
properly.
I think seth will chime in with the future of db_conn, relating to
issues like this.
Here I go:
Dispite it being possible, it really is a bad idea for all annotation
data packages to export the same symbols. We will be changing these:
db_conn and db_file prior to the release and replace them with
accessor functions prefixed with the package name: hgu95av2_dbcon()
(name subject to change until implemented).
Several packages exporting the same symbol has already bitten us.
Couldn't namespaces be used here, with something like
hgu95av2:::dbcon() instead ?
Yes, but this isn't a great solution because people that _did_ want to
use dbcon would have to use ':::' and IMO that should not be
encouraged -- things that are not exported should not be part of the
public interface.