On 04/01/2016 01:39 PM, Michael Lawrence wrote:
Yes, it's arbitrary R code that is evaluated, so paste0() would work.
You're right that it's a big door and could let people do weird
things. Do you foresee a problem with that?
Opening such a big door raises many questions. In addition to allowing
people do weird/crazy things (like putting calls to library()
or requireNamespace() etc... in them), NAMESPACE files with arbitrary
R code in them become more complicated to maintain and the tools for
parsing/processing them also become more complicated to write and
maintain.
Now we have a new category of errors that can happen at package
installation time: errors triggered by the evaluation of the R
expressions embedded in the NAMESPACE file. Hopefully 'R CMD INSTALL'
will report something that can be understood by mere mortals when this
happens.
Once you create the feeling that a NAMESPACE file is just a file
that contains arbitrary R code then people expect import(), export()
etc.. to be ordinary R functions with a man page (being able to do
?import would not hurt actually) and they'll naturally try to do
things like
unwanted_foo_symbols <- ... long and complicated expression
eventually calling user-defined helper
functions located in the NAMESPACE file ...
import(foo, except=unwanted_foo_symbols)
Can't blame them for that. But is this the kind of things that we're
ready to see in NAMESPACE files?
Also once you've open that door, people will naturally wonder why they
can use an R expression in the 'except' part of import( , except=) but
not elsewhere e.g. in
import(foo, only=paste0("bar", 1:10))
as a more elegant way of doing importFrom(foo, bar1, bar2, ..., bar10).
This dissymmetry between the syntax of "import only this" and "import
all except this" feels very arbitrary. If you don't support the
import( , only=) syntax, people might legitimately ask things like
do.call(importFrom, c(list("foo"), as.list(paste0("bar", 1:10))))
to work. Again, can't blame them for that. But do we want this kind of
things to work? I'm worried debugging NAMESPACE files would become a
full-time job...
I guess one could have implemented NAMESPACE parsing by evaluating the
code in an environment (inheriting from the base namespace) where
import(), export(), etc, were defined. Maybe there's a good reason why
it was not implemented that way.
I'm sure there is ;-)
H.
On Fri, Apr 1, 2016 at 12:55 PM, Hervé Pagès <hpa...@fredhutch.org> wrote:
On 03/31/2016 04:07 PM, Michael Lawrence wrote:
I agree. The importExcept idea also works that way: importExcept(foo, bar,
baz)
But import(foo, except=c(bar, baz)) reads better.
mmh... so R expressions with calls to base functions like base::c() are
making their way in the NAMESPACE file. That's opening a big door. Does
that mean that we'll be able to do things like:
import(foo, except=paste0("bar", 1:10))
Or maybe c(bar, baz) in your above example is just an arbitrary syntax
that just happens to look like an R expression but won't be evaluated
as such?
H.
On Thu, Mar 31, 2016 at 4:00 PM, <luke-tier...@uiowa.edu> wrote:
I don't think you want to separate it from the import. Better to allow
something like
import(foo, exclude=bar)
or
import(foo, exclude=c("bar", "baz"))
This seems reasonably natural and shouldn't be too hard to
implement. (But is has been a while since I've worked on this code).
Best,
luke
On Thu, 31 Mar 2016, Karim Mezhoud wrote:
I think "From" is needed to specify which package we want to exlude
functions.
I think excludeFrom (package, function) seems to be intuitive.
thanks,
Karim
On Thu, Mar 31, 2016 at 9:54 PM, Hervé Pagès <hpa...@fredhutch.org>
wrote:
On 03/31/2016 12:55 PM, Michael Lawrence wrote:
Probably should just stick to exact symbols for now. If there is a
case where a pattern is actually useful, rather than just an
obfuscation, we can extend the feature set.
Fair enough. Not really intuitive that excludeImport uses the same
syntax as (but does the opposite of) importFrom though. Maybe having
the name of the directive start with "import" would help e.g.
importExcept(hash, values) # opposite of importFrom(hash, values)
Thanks,
H.
On Thu, Mar 31, 2016 at 12:11 PM, Zhu, Lihua (Julie)
<julie....@umassmed.edu> wrote:
Herve,
That is a very interesting idea and works for me! Thanks!
importPatternFrom(IRanges, "^values$")
Best,
Julie
On 3/31/16 2:51 PM, "Bioc-devel on behalf of Hervé Pagès"
<bioc-devel-boun...@r-project.org on behalf of hpa...@fredhutch.org>
wrote:
On 03/30/2016 08:35 PM, Michael Lawrence wrote:
That would work, but R is not going to be happy about redundant
imports. Interactively, users would balk at symbol qualification.
There are two classes of conflict:
1) Same semantics, where a common generic would arbitrate, or one
package could depend on the other, and
2) Different semantics, in which case one of the functions should
probably be renamed, although that might not be practical or easy
to
agree upon.
When those approaches fail, qualification is the only recourse.
I will think about adding an excludeImport() or importAs().
What about having something like an importPatternFrom() directive
similar to the exportPattern() directive and have these directives
support some of the grep() toggles like 'ignore.case', 'fixed',
'invert' etc... ?
Then Julie could just do:
importPatternFrom(hash, "^values$", invert=TRUE)
H.
On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight
<rfligh...@gmail.com
wrote:
In the cases of having conflicting names, is it not appropriate
then
to use
the "package::function" form for calling a particular function?
On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence
<lawrence.mich...@gene.com>
wrote:
I can't find the hash function in IRanges. Are you sure it has
one?
On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
<julie....@umassmed.edu> wrote:
Michael,
I have the same user case as Kasper. Another example is that
both
IRanges
and hash packages have hash. I need to use the hash from the
hash
package
instead of the one from IRanges.
Best,
Julie
On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
<kasperdanielhan...@gmail.com> wrote:
My usecase is when I import() two packages who has a conflict in
a
name.
For example, both Biobase and matrixStats has both anyMissing
and
rowMedians. I am happy to get all of these two packages, but I
need
to
resolve the conflict. Since I want to keep the ones from
matrixStats I
know
need to figure out how to import Biobase selectively. Which I
can,
using
the tools from codetoolsBioC, but I would also be happy with an
importFromExcept(), which would make my life much easier.
Best,
Kasper
On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
<lawrence.mich...@gene.com> wrote:
I'm curious about which symbols you wouldn't want to import,
and
why.
On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
<julie....@umassmed.edu> wrote:
Hi,
Is there a function to import all the exported objects from a
package
except a few named ones in NAMESPACE file?
For example, I would like to import all the functions in
S4Vectors
except fold. Is there a way to specify this without listing
all
other
functions using importFrom?
Many thanks for your help!
Best regards,
Julie
********************************************
Lihua Julie Zhu, Ph.D
Research Professor
Department of Molecular, Cell and Cancer Biology (MCCB)
Head of MCCB Bioinformatics Core
Program in Molecular Medicine
Program in Bioinformatics and Integrative Biology
University of Massachusetts Medical School
364 Plantation Street, Room 613
Worcester, MA 01605
508-856-5256 phone
(508) 856 5460 fax
http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?From=SE&Perso
n=1134
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_ma
ilman_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeR
jY_w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=Rxzbh
vEdYoq-VrN42rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8
CzeHHAAJ5kmgmJxQ&e=
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mai
lman_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY
_w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEd
Yoq-VrN42rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeH
HAAJ5kmgmJxQ&e=
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailm
an_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4D
erPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEdYoq-Vr
N42rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHHAAJ5kmg
mJxQ&e=
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailma
n_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4Der
PlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEdYoq-VrN42
rfiK5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHHAAJ5kmgmJxQ
&e=
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman
_listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPl
OmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEdYoq-VrN42rfi
K5-UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHHAAJ5kmgmJxQ&e=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_
listinfo_bioc-2Ddevel&d=BQIF-g&c=WJBj9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOm
hQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5gJMlij5cC5bLU&m=RxzbhvEdYoq-VrN42rfiK5-
UIIwjUIHLTQjy9s7-pzs&s=TmgPkRkAcsTjcIVvzaBFADs-tx8CzeHHAAJ5kmgmJxQ&e=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
