<br><br><div><span class="gmail_quote">On 10/10/07, <b class="gmail_sendername">Andreas Pakulat</b> <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10.10.07 03:22:57, Thomas Braxton wrote:<br>> On 10/9/07, Nhuh Put <<a href="mailto:nhuh.put@web.de">nhuh.put@web.de</a>> wrote:<br>> will probably not now how it works and wonder why writing an empty (or null)
<br>> > QByteArray deletes the entry. This can lead to some nasty suprises.<br>><br>><br>> That's what API docs are for. Writing a null QByteArray will delete the<br>> entry, writing an empty QByteArray will store an empty entry in the config
<br>> file. null and empty are _not_ treated the same.<br><br>As I said before thats a surprising thing to users of the API because<br>QByteArray's own functions treat null the same as empty. Qt tells people<br>to use isEmpty() instead of isNull() always and that isNull() only
<br>exists for historical reasons.</blockquote><div><br class="webkit-block-placeholder"></div><div>That is precisely why it has to be explicitely mentioned in KConfigGroup API docs, I really need to finish writing those. 
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">So if you need a way to delete entries you should have introduced a<br>function thats called "deleteEntry" or at least a flag for writeEntry
<br>that makes it clear an entry is deleted.</blockquote><div><br class="webkit-block-placeholder"></div><div>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, no
 t just missing. That's the whole reason for [$d].
</div><div><br class="webkit-block-placeholder"></div><div>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.
</div><div>Trolltech's probably not gonna change the behavior of QByteArray before KDE 4.1 anyway so what difference does it make?</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
Such behavioural changes depending on the content of a variable are not<br>really good for a public API.</blockquote><div><br class="webkit-block-placeholder"></div><div>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?
</div></div><br>