I was kind of hoping to avoid reference classes. The optimization stuff it giving me enough headaches. I've used a local environment successfully in the Rtnmin package (it is a direct conversion from my brother's TN Matlab package, which was able to use "globals" there).
JN On 15-07-10 04:17 PM, Hadley Wickham wrote: > On Fri, Jul 10, 2015 at 12:50 PM, ProfJCNash <profjcn...@gmail.com> wrote: >> I have a general question about appropriate design for a fairly >> complicated package, as I am redesigning and rebuilding the optimx >> package. It will get a new name as it appears that the calls will change >> in order to accommodate new functionality. I plan to make it >> fairly easy to add new optimization (function minimization) tools. >> >> The query is whether to use an environment to hold all the common >> objects (functions, scaled functions, gradients, scaled gradients, >> hessians, scaled hessians, parameters, scaled parameters, program >> controls, algorithm tuning parameters, constraints, fixed parametes, >> some function value history, etc.) The alternative is a set of very >> long calls, especially when the function needing a quantity may be a >> couple of layers below the routine that creates or sets the values. >> >> The negative side is that the functions are not portable outside the >> package, so would not be exported. >> >> Before I dig into the heavy clay of code that this will need, I thought >> I should ask if there are issues I might be missing, as the local >> environment -- essentially "global" variables within the perimeter of >> the package -- would make the code a lot cleaner, and may offer some >> useful efficiencies in computation. > > If you want to store the same set of things for many optimisers, you > might want to consider using reference classes or R6. > > Hadley > ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
