[Bioc-devel] Environment/RSqlite db interaction

[Laurent Gautier]

2007/9/13, Seth Falcon <sfalcon at fhcrc.org>:
> "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 --
> >>
> >> 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"))
> >> > [1] TRUE
> >> >> exists("db_conn", as.environment("package:hgu95av2"), inherits=FALSE)
> >> > [1] 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.

Well, the effort for typing hgu95av2:::dbcon() rather then hgu95av2_dbcon()
does not look like too much, isn't it. ;-)

The point about non-exported objects is more interesting: what is the purpose of
namespaces ?
Is it to enforce an explicit definition of the object being accessed, or is it
to prevent users to access it (but without preventing them anyway,
since there is always ":::").
There is still "::", but... the objects will be imported in the search
path when the library is loaded anyway.

Encoding information into a variable name looks hackish (ooops, there is S3...).

Well, this might also be a topic for R-devel...


Just a thought,


Laurent

> > That would allow to have identical code within these annotation packages
> > (since these packages are generated programatically, code duplication
> > is presumably acceptable).
>
> We will change the name to have a package prefix (like just about
> every other object in these packages) very soon.
>
> + seth
>
> --
> Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
> BioC: http://bioconductor.org/
> Blog: http://userprimary.net/user/
>