Dear Seth, thank you very much for your helpful comments:
>I had a quick look and for what it's worth, a few comments... > >* Seems a bit more code than I would expect. Arguable, yes... > I think you have some use cases that I don't have ;-). hopefully I'm not the only one to have these cases :-) > In terms of general use, I would suggest making a stab at a > simplified version. I have tried to do something in that direction: * files startUpMessage.R / StartupUtilities.Rd now gather the code addressing a more general audience; (?"startupmsg") * files illustration.R / myStartupUtilities.Rd [ with mySMHandler, mystartupMessage, buildStartupMessage ] (?"mySMHandler") may be thought of an illustration of the concept (and hence should not enter general packages, I suppose) the revised code is available again under http://www.uni-bayreuth.de/departments/math/org/mathe7/R-devel/startupmsg_0.2.tar.gz > For example, what's the difference between startupMessage and > startupVersionMessage; are both needed? I guessed so: the idea is to have more than one type of StartupMessage, and suppressing should be done according to the type; I have rethought this now: instead of two (or more) subclasses of StartupMessage, I now have endowed class StartupMessage with an extra slot type, which currently is supposed to take one of the tree values + "version": version and title information from the DESCRIPTION file + "notabene": "nota bene"s on the package to be given at this prominent place + "information": (starting) pointers for more information on the package: -howto call the package help file, -howto inspect the NEWS file, -additional manuals/vignettes -URLs (but the code already supports arbitrarily many type values) > And linestarter? I agree: this should better be dealt with in a more general/flexible way by allowing + the developper using 'startupMessages' to use his own SMHandler (for /S/tartup/M/essage/Handler/) as illustrated in 'mystartupMessages' + the user of a package with 'startupMessages' to specify a suitable custom restart (see examples in ?"startupmsg") --- is achieved using your code example >* Consider adding a customizable restart. As it stands, startupmsg > doesn't give a user more control than message(). Now it does; I admit, I should have integrated your proposed elegant code right from the beginning. > That is, you can either muffle the messages or not. If I want to write > them to a file or prefix them with funny characters, doing so by grabbing > hold of the message before it is emitted via the restart seems like a > nice approach (although one could argue for a more general system > logging system that probably would not need the fancy condition > system use). Thank you again Peter ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
