On Sun, Dec 4, 2011 at 8:07 PM, Jeff Newmiller <jdnew...@dcn.davis.ca.us> wrote: > I prefer to think of namespaces as preventing clashes with similarly-named > functions in the main workspace or in other packages that might serve a > different need. > > Given that purpose, I don't think I would have confined that particular > function behind the namespace, because any other use of that name is likely > to duplicate the functionality of that particular function, and any > improvements to it probably ought to be incorporated into that particular > function just as much as any other implementation would deserve improvement.
The idea of hiding the the internals is that they can then be changed with reasonable likelihood that it won't affect users. Only those who attempted to circumvent the barriers put in place would be affected. For example, suppose that read.xls and the related Excel routines were to be changed so that internally they use C instead of perl. In that case findPerl would not serve any purpose in the package and the current design would allow it to be dropped. On the other hand, if the purpose of the package were specifically to interface to perl then it would make sense to export it. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
