[Bioc-devel] Environment/RSqlite db interaction

Seth Falcon sfalcon at fhcrc.org
Thu Sep 13 17:01:29 CEST 2007


"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.

> 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 --
especially for cases like this which are not accidental/uncontrollable
name collisions.


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



More information about the Bioc-devel mailing list