David Landgren writes: > Spencer Ogden wrote: > > > Any other suggestions as to how to handle sort of 'config' settings? > > Use named parameters. > > bisection( \&func ); > bisection( \&func, min => -100 ); > bisection( \&func, min => 20, max => 40 );
That's probably what I would do. It's still irritating if you want to make many calls to bisection all with the same (non-default) values of epsilon and max_iter, because then you have to specify them on every call, or use the global accessors to change the package variables, changes which will still be in affect elsewhere in your program (or in other modules, or in other programs you're sharing a mod_perl process with, or whatever). In some ways it'd be better to encourage people to modify the package variables directly, rather than using accessor functions, because then the changes can be localized: local $Math::RootFind::epsilon = 0.01; Another option when you want some data to be associated with some function calls is to put the data into an object and make method calls on it: my $thingy = Math::RootFind->new(max_iter => 12); $thingy->bisection(\&func, 20, 40); For the typical case, using the default values, you can avoid constructing an object and just use a class method: Math::RootFind->bisection(\&func, 20, 40); But while that solves the problem I don't like it: there are many modules on Cpan which provide similar OO interfaces, and I find them annoying to use. Having to call a class method when what you want is a function is rather tedious, and a little misleading. In this particular case we've avoided the unusual case of having to specify optional params multiple times at the expense of having to spell out the full class name on all calls in the usual case -- that's hardly a win. That can be addressed by making bisection be a hybrid that works as either an instance method call or a direct function call that can be imported, like CGI::param is. That's kind of messy though, and I'm not convinced the complexity is worth the effort: merely documenting the ways in which your module can be used then makes it look much more complicated than it actually is, which can be offputting. And the other reason why I don't like OO here is that I want an object to be modelling something tangible. Here we can have "a Math::RootFind", which doesn't really make sense, and I called the variable above "$thingy" because there isn't an obvious name for what it represents; that is often a red flag that such an entity is representing an artificial entity. Smylers
