list separator in config entries

[Thomas Braxton]

On 10/10/07, Andreas Pakulat <apaku at gmx.de> wrote:
>
> On 10.10.07 03:22:57, Thomas Braxton wrote:
> > On 10/9/07, Nhuh Put <nhuh.put at web.de> wrote:
> > will probably not now how it works and wonder why writing an empty (or
> null)
> > > QByteArray deletes the entry. This can lead to some nasty suprises.
> >
> >
> > That's what API docs are for. Writing a null QByteArray will delete the
> > entry, writing an empty QByteArray will store an empty entry in the
> config
> > file. null and empty are _not_ treated the same.
>
> As I said before thats a surprising thing to users of the API because
> QByteArray's own functions treat null the same as empty. Qt tells people
> to use isEmpty() instead of isNull() always and that isNull() only
> exists for historical reasons.


That is precisely why it has to be explicitely mentioned in KConfigGroup API
docs, I really need to finish writing those.

So if you need a way to delete entries you should have introduced a
> function thats called "deleteEntry" or at least a flag for writeEntry
> that makes it clear an entry is deleted.


maybe you should look at the code before you assume that I don't know what
I'm doing, there is a function called deleteEntry. And no it can't just call
KEntryMap::remove because what if a config file earlier in the stack defined
a default for the entry? if you don't mark the entry as deleted in the most
specific config then the value of the default becomes the value of the entry
the next time the config is read. That's the way cascading config files
work. If there is no value for an entry in the user's config file then the
value of the system-wide default is used. So if a user doesn't want the
system-wide default the entry has to be marked as deleted, not just missing.
That's the whole reason for [$d].

if KConfigGroup treats null and empty the same then how do you differentiate
between an entry that was stored empty and an entry that does not exist (i.e.
deleted or never eixisted)? Pretty much all of KDE expects to be able to
tell the difference, changing that would be very surprising.
Trolltech's probably not gonna change the behavior of QByteArray before KDE
4.1 anyway so what difference does it make?

Such behavioural changes depending on the content of a variable are not
> really good for a public API.


Huh? If the behavior of a function doesn't depend on the content of the
variable, then why pass the variable to the function in the first place?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071010/4a320010/attachment.htm>