[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