Benjamin Pflugmann <benjamin-svn-dev@pflugmann.de> writes:
> I think you missed Greg's point.
No, i see his point, i just disagree with it. I thought that
highlighting the contradiction i see in what he said might
provide some enlightenment as to why we disagree.
> There is a difference: As Greg pointed out, one never wants to
> change the default. More precisely: one might want to append to
> the list, but there should be no reason to ever change any
> existing item. As a whole list, it is configuration data, the
> default items are not.
What a strange way to conceive of it. The configuration data in
discussion is a list. This list has a default value, (1 2 3 4).
Changing the list to (1 2 3 4 a b c) is changing the list; that
all the default elements are present does not mean the list has
not been configured. To say that (1 2 3 4) is some default data
but the configurable list defaults to () but the administrator
may change it is true from a certain point of view, but it seems
a very contorted way to view things. Certainly it isn't the way
any application i've ever seen presents things.
> > If you want to have the defaults in
> > the code, that is fine, i will not argue against that.
> [...]
>
> That is exactly what he says: The default list is not configuration
> data, therefore it is not automatically bad style to put the default
> list into the code (this is what it was all about, before).
You quoted me out of context. It is true that i have no problem
with the default list being in the code. I *do* have a problem
with the natural consequence of your and Greg's point of view:
not being able to remove the default items from the list. The
list needs to be configurable, not described in some contorted
way such that the user is allowed only to add to the list, never
subtract from it.
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 19 01:09:01 2002