[Bioc-devel] Environment/RSqlite db interaction

[Laurent Gautier]

2007/9/13, Seth Falcon <sfalcon at fhcrc.org>:
> "Laurent Gautier" <lgautier at gmail.com> writes:
>
> > Well, the effort for typing hgu95av2:::dbcon() rather then hgu95av2_dbcon()
> > does not look like too much, isn't it. ;-)
>
> It isn't at all about typing.
>
> > 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.
>
> The purpose is to first make sure that package code gets what it is
> expecting when it asks for the value of a symbol, not some random
> value associated with the same symbol in some other place (from
> another package on the search path or that the user has defined).
> Secondly, namespaces allow us to declare what parts of the code are
> part of the public interface and which parts are not.  Just as it is
> valuable to discourage users of S4 objects from using '@' directly, it
> is valuable to discourage the use of ':::'.  As we evolve our software
> we struggle to make it as backward compatible as possible.  Without
> some encapsulation (methods instead of @, private functions) this task
> is impossible.

I am not disputing the intention here.

Discouraging the use of ":::" or "@" is not what I question, but the fact
that these functions are made readily available, and that they are therefore
easy to "misuse".
(A newcomer will not see any warning sign when reading what comes out
of help("@") or help(":::"). Would it make sense to override the documentation
pages when Biobase is loaded in order to state explicitly that their
usage is discouraged ?).


> > Encoding information into a variable name looks hackish (ooops,
> > there is S3...).
>
> I'm not trying to argue that name mangling is beautiful.  But given
> current practice of interactive use, I don't think we are ready for a
> world in which users must constantly use '::' to disambiguate --

In the current setting, I also say that's way too dangerous:
forgetting the "::" can make
one call the wrong function way too easily.
Until there is a way to load a package *without attaching its complete
exported namespace*
to the search path, I agree that "::" will remain a strange thing.

In other words, leaving objects in their namespace but without
declaring them "private".
## e.g.:
import("hgu95av2") ## hgu95av2 not added to the search path.
> dbcon()
Error: could not find function "dbcon"
> hgu95av2::dbcon()

...but that's more and more something for r-devel I guess.

> especially for cases like this which are not accidental/uncontrollable
> name collisions.
>

Then what about using a function (defined in a package required by all
annotation packages... say Biobase for example) ?

Something like:
  getDBcon("hgu95av2")

(I know that this is not any shorter... just a desperate attempt at
avoiding name mangling)


L.

> --
> Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
> BioC: http://bioconductor.org/
> Blog: http://userprimary.net/user/
>