[Rd] Suggestion: Allow packages to add additional information to sessionInfo()
Friedrich Leisch
Friedrich.Leisch at stat.uni-muenchen.de
Fri Sep 4 11:04:20 CEST 2009
>>>>> 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<krcoombes at 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
More information about the R-devel
mailing list