[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] encapsulation branch
From: |
Markus Schiltknecht |
Subject: |
[Monotone-devel] encapsulation branch |
Date: |
Thu, 19 Apr 2007 22:47:51 +0200 |
User-agent: |
Icedove 1.5.0.10 (X11/20070329) |
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...
Comments?
Regards
Markus
- [Monotone-devel] encapsulation branch,
Markus Schiltknecht <=