[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [BUG] feature plan -- version variables
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] [BUG] feature plan -- version variables |
Date: |
Tue, 25 May 2004 14:38:25 -0700 (PDT) |
> From: Aaron Bentley <address@hidden>
> > Suppose a variable is locally set to #f.
> > Then there's no reason to record in the patch log at all when a commit
> > happens. By omitting the variable from the patch log, you
> > effectively set its patch-log value to #f.
> Actually, I think it's worthwhile to preserve the distinction between
> missing and false. In my work, I frequently encounter variables that
> should be treated as true if missing, and I think the problem could only
> be worse with a metadata system. It's a distinction embraced by
> hackerlab's hashtrees and the C++'s std::map too.
> Because you have to be able to answer the question: did they
> deliberately disable that? Or were they unaware of the possibility of
> enabling that?
Yup, that'd be the opposing opinion on this, afaict, subjective call.
My feeling is that "default to #f" is dirt simple, fully general, easy
to understand, mostly easy to use, and in exceptional cases awkward.
I don't know any solution that has better properties. I know of many
that have "no worse" properties except for the one property "dirt
simple".
All else being equal, the simplest thing wins.
-t
Re: [Gnu-arch-users] [BUG] feature plan -- version variables, Bug Goo, 2004/05/28