search

markvanderloo / settings

An Option Manager for R
7 stars 4 forks source link

Transition to environments instead of lists #2

Open jamiefolson opened 9 years ago

jamiefolson commented 9 years ago

For a large number of settings variables there are performance advantages for using using environments (hash-tables) instead of lists (sequential search).

jamiefolson commented 9 years ago

I'd be happy to submit a pull request if this is something you'd be interested in.

markvanderloo commented 9 years ago

Interesting idea actually. We'd have to benchmark it but my feeling is that it wouldn't matter much unless you have thousands of settings. In the case I feel you're passing data, not settings :).

jamiefolson commented 9 years ago

Yup. It's mostly irrelevant unless you get lots of settings, but you can notice it even in the hundreds. The main advantage is that environments are mutable, so inheritance is a little more flexible. You could inherit from other settings rather than just copying and merging.

Jamie Olson

On Wed, Dec 17, 2014 at 4:22 PM, Mark van der Loo notifications@github.com wrote:

Interesting idea actually. We'd have to benchmark it but my feeling is that it wouldn't matter much unless you have thousands of settings. In the case I feel you're passing data, not settings :).

— Reply to this email directly or view it on GitHub https://github.com/markvanderloo/settings/issues/2#issuecomment-67396603 .

markvanderloo commented 9 years ago

Ok, I'm playing around with it a bit (only for 5 mins) in a local branch. I run into this question.

In you're proposal, suppose I have a settings manager SM and I do do a copy-and-merge to SM1 with a few new settings. If I understand correctly, you propose in #3 to to only store the new settings and point to the other ones by reference. In that case, suppose now, I change a setting in SM that SM1 points to. After this, what does it mean to reset SM1? Am I going to reset SM as well? (side-effect). Or, am I going to copy stuff that now differs (administration).

jamiefolson commented 9 years ago

I'm not 100% sure I understand the way defaults currently work, so I'm not sure what would be most consistent. If SM is a "default" for SM1, resetting SM1 would mean removing all variables in SM1 and inheriting the defaults from SM, but with environments, changes to SM would change the "default" values for SM1.

To be clear, this would result in changes to the current settings behavior. It might require making a some kind of distinction like "static" settings(lists) versus "dynamic" settings(environments).

Jamie Olson

On Wed, Dec 17, 2014 at 4:51 PM, Mark van der Loo notifications@github.com wrote:

Ok, I'm playing around with it a bit (only for 5 mins) in a local branch. I run into this question.

In you're proposal, suppose I have a settings manager SM and I do do a copy-and-merge to SM1 with a few new settings. If I understand correctly, you propose in #3 https://github.com/markvanderloo/settings/issues/3 to to only store the new settings and point to the other ones by reference. In that case, suppose now, I change a setting in SM that SM1 points to. After this, what does it mean to reset SM1? Am I going to reset SM as well? (side-effect). Or, am I going to copy stuff that now differs (administration).

— Reply to this email directly or view it on GitHub https://github.com/markvanderloo/settings/issues/2#issuecomment-67401239 .

markvanderloo commented 9 years ago

This R-dev thread may be of interest to you as well: http://r.789695.n4.nabble.com/Options-that-are-local-to-the-package-that-sets-them-td4699075.html