Even shorter, one could use the "::" operator and write org.Mm.eg.db::egCHRLOC. The presumed issue is more that one could import (attach) several org.X.eg.db packages, still write egCHRLOC and get something dependent on the order in which the import was made (hence the note about implementing the pattern "safely"). The only way around I can thing of would be to do not export names out a package namespace, forcing the use of ":::", but that's twisting things a little. L. On 12/1/10 7:37 PM, Iain Gallagher wrote: > You could write in a check and use 'with'. > > if 'mouse' > > yourFunction (with (org.Mm.eg.db... etc etc)) > > if 'human' > > yourFunction (with (org.Hs.eg.db... etc etc)) > > This might not be optimal as I'm not a programmer by any measure (!) but it's one way to get what I think you want. > > cheers > > iain > > --- On Wed, 1/12/10, Laurent Gautier<laurent at="" cbs.dtu.dk=""> wrote: > >> From: Laurent Gautier<laurent at="" cbs.dtu.dk=""> >> Subject: Re: [BioC] org.*.eg.db problem >> To: arne.mueller at novartis.com >> Cc: bioconductor at stat.math.ethz.ch >> Date: Wednesday, 1 December, 2010, 17:28 >> On 01/12/10 17:50, Martin Morgan >> wrote: >>> On 12/01/2010 08:48 AM, arne.mueller at novartis.com >> wrote: >>>> Hello, >>>> >>>> the org.*.eg.db environments cannot be used in a >> generic way :-( . Let's >>>> say I'm writing a function that needs an entire >> org.*.eg.db environment as >>>> argument, and the function doesn't care whether >> it's human, mouse rat or >>>> jellyfish. Inside my function I'd be required >> accessing the maps (e.g. for >>>> chromosomal location) without knowing the species. >> The problem is that you >>>> do need to know the species because the mapping >> names use the species >>>> abbreviation: >>>> >>>>> org.Mm.egCHRLOC >>>> CHRLOC map for Mouse (object of class "AnnDbMap") >>>> >>>> Why isn't this more generic so that one could just >> call egCHRLOC instead >>>> of org.Mm.egCHRLOC which makes code that uses this >> annotation having to >>>> know about the organism - why does it have to be >> be hard coded? Ideally >>>> I'd like to be able to do the following: >>>> >> This is likely a design decision forced by R's scoping rule >> for attached >> packages: attaching a package will bring its (exported) >> content into the >> search path. >> In other words, if you would have a package org.Mm.eg.db >> and a package >> org.Hs.eg.db, both containing an object egCHRLOC, the >> symbol egCHRLOC >> would be resolved to two different things depending on >> which one of the >> two packages was attached last. >> >> This does prevent some of the patterns frequently found in >> other >> language from being (safely) implemented >> (and is unfortunate). >> >> >>>>> library(org.Mm.eg.db) >>>>> myGenomeAnnotationFunction(org.Mm.eg.db) >> { # pass in as an environment? >>>> # use the annotation >> environment to extract whatever information ... >>>> } >>>> >>>> How would you solve this when having to work with >> several species (if else >>>> ... ???) >>>> >>> Hi arne -- >>> >>> For many cases, >>> >>> library(annotate) >>> map<- getAnnMap("CHRLOC", "org.Mm.eg.db") >>> >>> which will take care of loading the org package as >> well. >>> Martin >>> >>> >>>> thanks a lot for your help, >>>> >>>> Arne >>>> >>>> >>>> >>>> >>>> [[alternative HTML version >> deleted]] >>>> _______________________________________________ >>>> Bioconductor mailing list >>>> Bioconductor at r-project.org >>>> https://stat.ethz.ch/mailman/listinfo/bioconductor >>>> Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor >> _______________________________________________ >> Bioconductor mailing list >> Bioconductor at r-project.org >> https://stat.ethz.ch/mailman/listinfo/bioconductor >> Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor >> > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor