[RFC] KConfig API stuff

[Oswald Buddenhagen]

On Sun, Oct 21, 2007 at 11:58:58AM -0500, Thomas Braxton wrote:
> since you seem to think I'm a less than capable coder,
>
you made quite some mistakes and proved astonishingly resistant to
argumentation. make of that whatever you feel like.

> On 10/21/07, Oswald Buddenhagen <ossi at kde.org> wrote:
> > - kill kconfigbase, make kconfig inherit kconfiggroup.
> 
> It wasn't my idea, puthunh convinced me to readd it to the heirarchy.
> kconfigbase was gone from my branch.
> 
i know. he was misguided into thinking that it would make setGroup come
back. he didn't realize that making the kconfig object only the root
group is an option. we fixed that misconception. :-)

> >  - rationale: it is The Right Thing To Do (TM). the current asymmetry
> >     of kconfig offering the group functions but no entry functions is
> >     just awkward. the kconfig object itself is the <default> group (the
> >     root group, or rather, the non-group) and should behave as such.
> 
> actually I would say that the kconfig object is not the default group, but
> is rather the collection of *all* groups. groups also don't care about the
> backend.
>
yes, that's the alternative view. in principle, the config would be the
backend/workhorse of the groups.

> this seems like making a collection of items a subclass of the item.
>
yes, that's how recursive collections work. ;-)

> that's why kconfig offers the group functions, it is a collection of
> groups. a group is a collection of entries, that's why kconfiggroup
> offers the entry functions. the reason kconfiggroup also offers the
> group functions is because a group can have subgroups.
> 
yes. and why does the default group contain other groups but has the
same direct parent as its children? sounds like incest, heh.

> > - renames in kconfiggroup: name to groupName, exists to groupExists,
> >   rename in kconfig: name to configName
> >   - rationale: clearly necessary with the changed hierarchy. does it
> >     make sense without it?
> 
> if they aren't going to have a common ancestor, the current
> names are still valid, why would you ask a group what it's groupName is?
> group.name() makes more sense than group.groupName(). config.name() makes
> more sense than config.configName(). is there another name that they are
> going to return in another function that requires the longer names?
> 
- it's the Qt way to call functions. of course, this is motivated by
  deep hierarchies, which isn't going to happen with kconfig. anyway ...
- the objects are often enough named c, cf, cg, etc., also with the
  rationale of less typing. many are even "misnamed" (if you assume cf
  actually means anything) as the result of quick porting away from
  deprecated methods.
  now one could argue that the lib should not attempt to "fix"
  overconcise code ... or the opposite.

> > - rename kconfiggroup::clean back to to rollback.
> >   - rationale: whoever renamed it had no idea of database terminology
> 
> you're right I don't know database terminology, but I know enough to know
> that to rollback a db means to return to some previous state, which this
> doesn't do. That's why I thought the name should be changed, to reflect what
> it actually does and not pretend it does more.
> 
hmm, you're right, it doesn't really do a rollback (it doesn't re-read
the entries). however, "clean" is as undescriptive as it gets. "undirty"
sounds weird, but immediately rings a bell with anybody who knows
something about writeback semantics. deal?

> > - remove kconfiggroup::group
> >   - rationale: it is just a weird way to call the constructor:
> 
> Actually I was thinking of going the other way, to make read-only groups
> work correctly. make all the constructors protected except KConfigGroup() &
> KConfigGroup(const KConfigGroup&).
> 
hmm. we have some additional problems due to the shared pointer stuff.
i don't really understand this const stuff without a lot of thinking.
puthuhn and dfaure discussed it and concluded that we won't get it right
anyway.

> > - remove kconfiggroup::getConfigState
> >   - rationale: the api suggests a granularity that is simply not given.
>
> Again, another addition from puthuhn.
> 
i know. he was thinking about the windows registry which could provide
this granularity. ldap could also. however, this isn't entirely thought
out. need to reconsider myself.

> > - move kconfiggroup::setReadDefaults to kconfig
> 
> another problem, how do you ensure that it is set on every group that
> comes from a config object that is supposed to be reading defaults
> only?
> 
hmm? as it would be set on the kconfig object, every group would be
affected, whether created in advance or afterwards setting this flag.

> > - remove kconfig::setForceGlobal
> >   - rationale: only user is kfile/kfilewidget.cpp. the alternative
> >     api is passing the KConfigGroup::Global flag to writeEntry calls.
> 
> actually it's also set whenever "kdeglobals" is opened explicitely, so
> that whoever is using it doesn't have to pass KConfigGroup::Global to
> every writeEntry call.
> 
you're again confusing internals with api. ;-)

> > - remove kconfig OnlyLocal and NoGlobals
> >   - rationale: they are aliases for SimpleConfig resp. CascadeConfig.
> >     it's more to learn and the negative meanings are potentially
> >     confusing.
> 
> That's why I changed the names.
> 
nobody said that everything you did was crap or everything somebody else
did shines. ;-)

> > - remove kconfiggroup::entryMap
> >   - rationale: the api sucks. it wants to return all values as strings,
> >     which might be simply impossible without quite some additional magic
> >     with some backends.
> 
> I was thinking about changing this to return QMap<QString,QVariant>,
>
i was, too. but it looks weird if the user gets once a string and once a
number, depending on the backend.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.