monotone-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]