[darcs-devel] DarcsFlags propagation reduction

[David Roundy]

On Sun, Jul 22, 2007 at 05:38:00PM -0400, Zachary P. Landau wrote:
> On Mon, Jul 02, 2007 at 03:17:06PM -0700, quick at sparq.org wrote:
> > This patch may be a little controversial, so I'm prepared to entertain
> > discussion and rework this if needed.
> > 
> > It appears that originally, the command-line options were passed around
> > to various functions as the [DarcsFlag] argument, but that eventually
> > these options were bound into the Repository class when the latter is
> > created (usually via withRepoLock).  This patch removes the explicit
> > [DarcsFlag] argument where the flags are available via the Repository
> > argument instead.  The intent is to cleanup the interfaces and prevent
> > confusion arising from having two different sources for the same
> > information.
> 
> <snip>
> 
> Eric has this under Waiting for discussion, and after all the issues he
> addressed this week, the least I can do is try to start the discussion
> on this.
> 
> I agree that its a good idea not to present two sources for the same
> information.  I can't think of a particularly strong argument for why
> this is a bad idea.  It touches on a lot of code, but now feels like a
> good time for that sort of cleanup.

The motivation behind having the separate sources of information is that we
can thus make explicit when the behavior of a function explicitly depends
on the arguments, versus implicitly via the Repository functions.  I think
this is a useful distinction, as the Repository functions are designed such
that in a certain sense their *semantics* do not depend on the flags passed
(in another sense their semantics do, but the intent is that this second
sense is one that can be ignored by users of these functions).

This encapsulation also allows repositories to manipulate their own
DarcsFlags without affecting the semantics of the programs.  Darcs has long
modified [DarcsFlag] as a way of passing parameters around, and this
insulates these uses.

I could certainly be convinced that making the Repository-internal
[DarcsFlag] public could be a good idea, but it wasn't an oversight that
made it private, but rather a desire for encapsulation, and to make
explicit functions whose behavior explicitly depends on the [DarcsFlag].
Also note, that it wouldn't be hard to stick [DarcsFlag] into a global
variable, but we don't do this for precisely the same reason: we want to be
able to, for example, remove "Verbose" from the flags passed to a function
if we know that it's going to be called too many times.
-- 
David Roundy
http://www.darcs.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070724/26b095cc/attachment.pgp