>>>>> On Thu, 3 Sep 2009 11:10:31 -0700, >>>>> Henrik Bengtsson (HB) wrote:
> On Thu, Sep 3, 2009 at 10:38 AM, Kevin R. > Coombes<krcoom...@mdacc.tmc.edu> wrote: >> [1] I agree that sessionInfo() can be taken further. >> [2] I even more strongly agree that it would be a bad idea to allow packages >> to add features that cause the base sessionInfo() function to fail. >> >> Why not add an extra function called something like "packageSessionInfo()" >> that would provide the desired hooks but keep them from breaking the base >> functionality? > The point is that (if so) there should only be *one function* to call > for all packages, not one per package, because that would be a pain > due to dependencies. But, sure I'm happy to start with a > package[s]SessionInfo() such that > c(sessionInfo(), extras=packagesSessionInfo()) > pretty much return what I wish. Then it might be easier to argue for > incorporating the above in sessionInfo() ;) > Sorry for not getting it, but I still don't see how adding extra > information would break the base functionality? Can you give some > examples? > As I said, timeouts can be a problem and possibly also if the hook > functions have side effects that, say, would load new packages, could > give funny results, but I also think a package developer who is > capable to setting up hook function would no how to avoid this. > With the default argument of 'extras' to be FALSE, sessionInfo() would > work as now, with the extra feature that 'extras=TRUE' can give lots > of additional useful information. I think the concept of hook functions for sessionInfo() makes absolute sense. Yes it should be optional to run them, but the default should be pkghooks=TRUE, because I don't see why they shouldn't run OK in 99.9% of all cases. If a hook doesn't run on a certain platform that would be a bug to me and need to be fixed. Could those who seem to think such hooks are not a good idea elaborate on what the "danger" really is? Best, Fritz ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
