On Thu, Aug 23, 2018 at 3:46 PM Duncan Murdoch <murdoch.dun...@gmail.com> wrote: > > First, some general comments: > > This sounds like a useful package. > > I would guess it has very little impact on runtime efficiency except > when attaching a new package; have you checked that?
It adds one extra element to the search path, so the impact on speed should be equivalent to loading one additional package (i.e. negligible) I've also done some benchmarking to see the impact on calls to library(). These are now a little outdated (because I've added more heuristics so I should re-do), but previously conflicted added about 100 ms overhead to a library() call when I had ~170 packages loaded (the most I could load without running out of dlls). > I am not so sure about your heuristics. Can they be disabled, so the > user is always forced to make the choice? Even when a function is > intended to adhere to the superset principle, they don't always get it > right, so a really careful user should always do explicit disambiguation. That is a good question - my intuition is always to start with less user control as it makes it easier to get the core ideas right, and it's easy to add more control later (whereas if you later take it away, people get unhappy). Maybe it's natural to have a function that does the opposite of conflict_prefer(), and declare that something that doesn't appear to be a conflict actually is? I don't think that an option to suppress the superset principle altogether will work - my sense is that it will generate too many false positives, to the point where you'll get frustrated and stop using conflicted. > And of course, if users wrote most of their long scripts as packages > instead of as long scripts, the ambiguity issue would arise far less > often, because namespaces in packages are intended to solve the same > problem as your package does. Agreed. > One more comment inline about a typo, possibly in an error message. Thanks for spotting; fixed in devel now. Hadley -- http://hadley.nz ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel