[PATCH] remove UDSEntry from the public KIO API?
Jeff Mitchell
kde-dev at emailgoeshere.com
Mon Jul 23 14:40:09 BST 2007
Thiago Macieira wrote:
> nf2 wrote:
>
>> Thiago Macieira wrote:
>>
>>> This hides the details of UDSEntry and UDSField from the public. The
>>> question is now? Should we commit? Norbert, does it help towards your
>>> goal?
>>>
>> Cool. I have seen you have also fixed the KioSlaveTest (which i have
>> just commented out). And udsentry.cpp looks a lot nicer now.
>>
>> I think the patch should be commited - everything which makes the
>> KIO-API more generic and extensible (without having to break the API)
>> will help you in the future. No matter if the future is GVFS or not.
>>
>
> I'm not doing a "commit if no objections" on this one.
>
> Someone else please OK this within the next 12 hours, or this patch will
> be out of KDE until KDE 5.0.
>
> For ease of reading the patch, here's the most relevant part.
>
>
I'm currently working with UDSEntry and having taken a look at the diff,
the one question I have is why there's no operator[]. Norbert said:
"Regarding the operator[] i'm not sure - i would prefer a method which
returns an array of ints (a QList<uint> getListOfFieldIds()) because
there might be QList<QString> getListOfFieldNames() in the future..."
Is there a reason not to have both? I know that it's no longer a QHash
derivative (since that's in the private class now), but it would help
ensure ease of transitioning to the new code/backwards compatibility.
Regardless, I like some of the new methods, and in general I am in favor
of code cleanup and future proofing, so FWIW here's an OK from me.
--Jeff
More information about the kde-core-devel
mailing list