Hi,
as you might have noticed, I've done some work in
nvm.experiment.encapsulation. Based on Zack's idea, I've removed
the app_state from lots of functions and objects. This has two
reasons:
- reducing the amount headers included
- allow for read only database functionality (which is enforced by
the compiler)
Please have a look at rev 910e5113c9cec2c451fc4fe086c4793475a29606,
where I have those four macros:
AUTOMATE_WITH_EVERYTHING(..
AUTOMATE_WITH_DATABASE(..
AUTOMATE_WITH_WORKSPACE(..
AUTOMATE_WITH_NOTHING(..
Currently, I'm using some stub functions and I still heavily rely
on having the app_state around in the database context. Anyway, for
me, the point of the exercise is, finding out if it's worthwhile to
achieve the above two goals.
After lots of shuffling around of method arguments and such, I feel
like walking on thin ice. I'd like to get some input. What do you
think, is this the right way to do it? Shall we get rid of the
app_state completely? What's the best way to handle commands with
different requirements, i.e. ones need only a readable database,
others want to write to the database and need a key_store, others
need the workspace and a key_store, etc... I don't particularly
like the #define's...